<div dir="ltr"><div><div>1 << 31 poll is not a decision in the sense that the committee decided to make the change. The polled option is contradictory with the option polled immediately after.<br></div>The second option has more consensus in the context of the group in the room, but it simply means that both options may be further explored.<br><br></div>-- HT<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 16, 2018 at 3:06 PM, Myria <span dir="ltr"><<a href="mailto:myriachan@gmail.com" target="_blank">myriachan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I really don't like this decision on 1 << 31 at all. I've already<br>
written code that is in a production library that uses 1 << 31 in a<br>
constexpr context, which would be ill-formed.<br>
<br>
On Fri, Mar 16, 2018 at 11:20 AM, Arthur O'Dwyer<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>> wrote:<br>
> (Dropped some marginally relevant lists I get mod-queued on anyway)<br>
><br>
>> The notes should help clarify RIchard's rationale for proposing this.<br>
><br>
> <a href="http://wiki.edg.com/bin/view/Wg21jacksonville2018/Sg6P0907R0" rel="noreferrer" target="_blank">http://wiki.edg.com/bin/view/<wbr>Wg21jacksonville2018/<wbr>Sg6P0907R0</a> has some<br>
> discussion from Richard (Smith?) about (1<<32) needing to remain IDB-at-best<br>
> on x86 platforms (Ctrl+F "crypto"). Total agreement on that front.<br>
> I don't see any notes on that page which are relevant to (1<<31) — there's<br>
> just the straw poll results with zero prior discussion notated.<br>
><br>
>> Shifting out of range (1 << 31) as currently defined (if shift has defined<br>
>> value when interpreted as unsigned, you get the value as signed, you can<br>
>> dhigt into but not past the sign, shifting past sign bit is UB), 1<<31 was<br>
>> defined and still is (as of Howard's paper), 2<<31 was UB and still is, WG14<br>
>> is currently considering whether to adopt Howard's paper which made this.<br>
>> Should we take it back to undefined to do 1<<31?<br>
>> SS F N A SA<br>
>> 2 7 5 1 1<br>
><br>
><br>
> Am I looking at the wrong page, perhaps?<br>
><br>
> Thanks,<br>
> Arthur<br>
><br>
> P.S. — Alternatively, since 0x80000000 is allowed to be a trap<br>
> representation in P0907r1 but 0xC0000000 is not, perhaps the intent of this<br>
> straw poll was that 1<<31 should be UB but 3<<30 should be well-defined.<br>
> That would be extra weird, though, so I hope that's not what happened.<br>
><br>
><br>
> On Fri, Mar 16, 2018 at 11:06 AM, JF Bastien <<a href="mailto:cxx@jfbastien.com">cxx@jfbastien.com</a>> wrote:<br>
>><br>
>> On Fri, Mar 16, 2018 at 2:04 PM, Arthur O'Dwyer<br>
>> <<a href="mailto:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>> wrote:<br>
>>><br>
>>> P0907r1 proposes this addition relative to the WD:<br>
>>><br>
>>> > If overflow caused by an operation which would require representing an<br>
>>> > integer which cannot be represented by the type, the behavior is undefined.<br>
>>><br>
>>> However, it simultaneously proposes these deletions relative to the WD:<br>
>>><br>
>>> > [Note: Operators can be regrouped according to the usual mathematical<br>
>>> > rules only where the operators really are associative or commutative ...<br>
>>> and<br>
>>> > an operation that would have undefined behavior as specified in Clause<br>
>>> > 4 through 19 of this document [Note: including, for example, signed integer<br>
>>> > overflow, certain pointer arithmetic, division by zero, or certain shift<br>
>>> > operations —end note]<br>
>>><br>
>>> The removals are all non-normative, but they seem to be aimed at<br>
>>> eliminating references to "signed overflow is UB", even though signed<br>
>>> overflow is still UB. Was there a sense in the room that we wanted to<br>
>>> downplay the importance of teaching signed UB in C++, but not actually<br>
>>> eliminate the UB itself? Or what's the point of re-wording these existing<br>
>>> notes?<br>
>><br>
>><br>
>> There was extensive discussion of this note, what to add / remove, etc,<br>
>> and no direction as to where to go. I'll ask EWG today.<br>
>><br>
>>><br>
>>> Also, separately and less importantly, I'd love to hear someone's<br>
>>> rationale for making (1<<31) UB in C++2a when it's IDB in C++17. The straw<br>
>>> poll result in P0907r1 sounds unambiguous, but I don't understand what<br>
>>> rationale could exist for taking this construct from IDB into UB. Is the<br>
>>> assumption that people haven't yet had a chance to write any programs whose<br>
>>> correctness depends on the value of (1<<31), so if we change it back to UB<br>
>>> fast enough, nobody will notice?<br>
>><br>
>><br>
>> The notes should help clarify RIchard's rationale for proposing this.<br>
>><br>
>>><br>
>>> –Arthur<br>
>>><br>
>>><br>
>>><br>
>>> On Fri, Mar 16, 2018 at 8:56 AM, JF Bastien <<a href="mailto:cxx@jfbastien.com">cxx@jfbastien.com</a>> wrote:<br>
>>>><br>
>>>> Hello EWG,<br>
>>>><br>
>>>> SG6 and SG12 discussed wg21.link/P0907r0 Signed Integers are Two’s<br>
>>>> Complement and provided extensive feedback.<br>
>>>><br>
>>>> I've attached an updated paper listing polls and addressing most<br>
>>>> feedback (except some wording fiddle) to the EWG wiki for this afternoon's<br>
>>>> discussion:<br>
>>>><br>
>>>><br>
>>>> <a href="http://wiki.edg.com/pub/Wg21jacksonville2018/EvolutionWorkingGroup/D0907r1.html" rel="noreferrer" target="_blank">http://wiki.edg.com/pub/<wbr>Wg21jacksonville2018/<wbr>EvolutionWorkingGroup/D0907r1.<wbr>html</a><br>
>>>><br>
>>>><br>
>>>> Thanks,<br>
>>>><br>
>>>> JF<br>
>>>><br>
>>>><br>
>>>> ______________________________<wbr>_________________<br>
>>>> ub mailing list<br>
>>>> <a href="mailto:ub@isocpp.open-std.org">ub@isocpp.open-std.org</a><br>
>>>> <a href="http://www.open-std.org/mailman/listinfo/ub" rel="noreferrer" target="_blank">http://www.open-std.org/<wbr>mailman/listinfo/ub</a><br>
>>>><br>
>>><br>
>><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> ub mailing list<br>
> <a href="mailto:ub@isocpp.open-std.org">ub@isocpp.open-std.org</a><br>
> <a href="http://www.open-std.org/mailman/listinfo/ub" rel="noreferrer" target="_blank">http://www.open-std.org/<wbr>mailman/listinfo/ub</a><br>
><br>
______________________________<wbr>_________________<br>
ub mailing list<br>
<a href="mailto:ub@isocpp.open-std.org">ub@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/ub" rel="noreferrer" target="_blank">http://www.open-std.org/<wbr>mailman/listinfo/ub</a><br>
</div></div></blockquote></div><br></div>