On Fri, 16 Mar 2018, 14:20 Arthur O'Dwyer, <arthur.j.odwyer_at_[hidden]>
wrote:

> (Dropped some marginally relevant lists I get mod-queued on anyway)
>
> > The notes should help clarify RIchard's rationale for proposing this.
>
> http://wiki.edg.com/bin/view/Wg21jacksonville2018/Sg6P0907R0 has some
> discussion from Richard (Smith?) about (1<<32) needing to remain
> IDB-at-best on x86 platforms (Ctrl+F "crypto"). Total agreement on that
> front.
> I don't see any notes on that page which are relevant to (1<<31) — there's
> just the straw poll results with zero prior discussion notated.
>

My rationale for wanting *some* change here is that the status quo is
inconsistent, and satisfies neither the "<< means multiplication" nor the
"<< means bit shift" perspective. I want one or the other, or a really good
reason for the status quo.

And, FWIW, the bit shift option was my preference.

Shifting out of range (1 << 31) as currently defined (if shift has defined
>> value when interpreted as unsigned, you get the value as signed, you can
>> dhigt into but not past the sign, shifting past sign bit is UB), 1<<31 was
>> defined and still is (as of Howard's paper), 2<<31 was UB and still is,
>> WG14 is currently considering whether to adopt Howard's paper which made
>> this. Should we take it back to undefined to do 1<<31?
>> SS F N A SA
>> 2 7 5 1 1
>
>
> Am I looking at the wrong page, perhaps?
>
> Thanks,
> Arthur
>
> P.S. — Alternatively, since 0x80000000 is allowed to be a trap
> representation in P0907r1 but 0xC0000000 is not, perhaps the intent of this
> straw poll was that 1<<31 should be UB but 3<<30 should be well-defined.
> That would be extra weird, though, so I hope that's not what happened.
>
>
> On Fri, Mar 16, 2018 at 11:06 AM, JF Bastien <cxx_at_[hidden]> wrote:
>
>> On Fri, Mar 16, 2018 at 2:04 PM, Arthur O'Dwyer <
>> arthur.j.odwyer_at_[hidden]> wrote:
>>
>>> P0907r1 proposes this addition relative to the WD:
>>>
>>> > If overflow caused by an operation which would require representing
>>> an integer which cannot be represented by the type, the behavior is
>>> undefined.
>>>
>>> However, it simultaneously proposes these deletions relative to the WD:
>>>
>>> > [*Note:* Operators can be regrouped according to the usual
>>> mathematical rules only where the operators really are associative or
>>> commutative ...
>>> and
>>> > an operation that would have undefined behavior as specified in
>>> Clause 4 through 19 of this document [*Note*: including, for example, signed
>>> integer overflow, certain pointer arithmetic, division by zero, or
>>> certain shift operations —*end note*]
>>>
>>> The removals are all non-normative, but they seem to be aimed at
>>> eliminating references to "signed overflow is UB", even though signed
>>> overflow *is* still UB. Was there a sense in the room that we wanted to
>>> downplay the importance of *teaching* signed UB in C++, but not
>>> actually eliminate the UB itself? Or what's the point of re-wording these
>>> existing notes?
>>>
>>
>> There was extensive discussion of this note, what to add / remove, etc,
>> and no direction as to where to go. I'll ask EWG today.
>>
>>
>>> Also, separately and less importantly, I'd love to hear someone's
>>> rationale for making (1<<31) UB in C++2a when it's IDB in C++17. The straw
>>> poll result in P0907r1 sounds unambiguous, but I don't understand what
>>> rationale could exist for taking this construct from IDB into UB. Is the
>>> assumption that people haven't yet had a chance to write any programs whose
>>> correctness depends on the value of (1<<31), so if we change it back to UB
>>> fast enough, nobody will notice?
>>>
>>
>> The notes should help clarify RIchard's rationale for proposing this.
>>
>>
>>> –Arthur
>>>
>>>
>>>
>>> On Fri, Mar 16, 2018 at 8:56 AM, JF Bastien <cxx_at_[hidden]> wrote:
>>>
>>>> Hello EWG,
>>>>
>>>> SG6 and SG12 discussed wg21.link/P0907r0 Signed Integers are Two’s
>>>> Complement and provided extensive feedback.
>>>>
>>>> I've attached an updated paper listing polls and addressing most
>>>> feedback (except some wording fiddle) to the EWG wiki for this afternoon's
>>>> discussion:
>>>>
>>>>
>>>> http://wiki.edg.com/pub/Wg21jacksonville2018/EvolutionWorkingGroup/D0907r1.html
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> JF
>>>>
>>>>
>>>> _______________________________________________
>>>> ub mailing list
>>>> ub_at_[hidden]
>>>> http://www.open-std.org/mailman/listinfo/ub
>>>>
>>>>
>>>
>>
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>