(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.

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/EvolutionWorkin
>>> gGroup/D0907r1.html
>>>
>>>
>>> Thanks,
>>>
>>> JF
>>>
>>>
>>> _______________________________________________
>>> ub mailing list
>>> ub_at_[hidden]
>>> http://www.open-std.org/mailman/listinfo/ub
>>>
>>>
>>
>