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