I really don't like this decision on 1 << 31 at all. I've already
written code that is in a production library that uses 1 << 31 in a
constexpr context, which would be ill-formed.

On Fri, Mar 16, 2018 at 11:20 AM, 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.
>
>> 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
>