<div dir="ltr">On Fri, Oct 25, 2013 at 5:57 PM, Lawrence Crowl <span dir="ltr">&lt;<a href="mailto:Lawrence@crowl.org" target="_blank">Lawrence@crowl.org</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/25/13, Richard Smith &lt;<a href="mailto:richardsmith@google.com">richardsmith@google.com</a>&gt; wrote:<br>
&gt; On Oct 25, 2013, Gabriel Dos Reis &lt;<a href="mailto:gdr@axiomatics.org">gdr@axiomatics.org</a>&gt;wrote:<br>
&gt; &gt; Matt Austern &lt;<a href="mailto:austern@google.com">austern@google.com</a>&gt; writes:<br>
<div><div class="h5">&gt; &gt; &gt; On  Oct 25, 2013, Jeffrey Yasskin &lt;<a href="mailto:jyasskin@google.com">jyasskin@google.com</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt; Richard explicitly asked whether any such C++ users exist or<br>
&gt; &gt; &gt; &gt; are likely to exist in the future, and nobody&#39;s come up with<br>
&gt; &gt; &gt; &gt; any examples.  So we appear to have a choice between helping<br>
&gt; &gt; &gt; &gt; some theoretical people or helping some actual people. (We<br>
&gt; &gt; &gt; &gt; help the actual people by telling them what to expect in the<br>
&gt; &gt; &gt; &gt; standard, while now they have to test and hope they find the<br>
&gt; &gt; &gt; &gt; right subset of undefined or implementation-defined behavior<br>
&gt; &gt; &gt; &gt; that&#39;s actually guaranteed to work.)<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; It&#39;s actually a little worse than that. Testing can reveal<br>
&gt; &gt; &gt; what your implementation does today, with your particular<br>
&gt; &gt; &gt; input, with one set of compiler flags. No amount of testing<br>
&gt; &gt; &gt; can reveal what guarantees your implementation makes.<br>
&gt; &gt;<br>
&gt; &gt; There are two separate issues here:<br>
&gt; &gt;<br>
&gt; &gt;   (1) whether we want C++ to continue to support non-two&#39;s<br>
&gt; &gt;       complement binary representation<br>
&gt; &gt;   (2) what we want to say about overflowing shift arithmetic<br>
&gt; &gt;<br>
&gt; &gt; Requirint two&#39;s complement does not necessarily solve (2).  And<br>
&gt; &gt; solving (2) does not necessarily imply &quot;no&quot; to (1).<br>
&gt;<br>
&gt; Agreed. It would definitely be interesting to complete Jeffrey&#39;s<br>
&gt; list of the things we could define if we standardized 2s<br>
&gt; complement, and then investigate how many of these we are<br>
&gt; comfortable defining without specifying 2s complement. So far, we<br>
&gt; have:<br>
&gt;<br>
&gt; 1) overflowing unsigned-&gt;signed conversions<br>
&gt; 2) right-shifts on negative operands<br>
&gt; 3) bitwise operators<br>
&gt;<br>
&gt; Are there others?<br>
<br>
</div></div>While we are on this topic, we should list that defining a<br>
two&#39;s complement representation will exclude using 1000... as<br>
a trap value.  I think that is the right decision once you have<br>
bitwise operators, because -1^INT_MAX yields the bit pattern.<br>
<div class="im"><br>
&gt; (1) and (2) are currently implementation-defined;<br>
<br>
</div>(1) is almost always the inverse of signed-&gt;unsigned conversion.<br>
However, I am not excited about either.  I want a run-time<br>
diagnosis when I convert a negative number to unsigned or when<br>
I overflow a signed number when converting from unsigned.  This<br>
diagnosis could happen from a new conversion operator, e.g.<br>
checked_cast&lt;unsigned int&gt;(-3).<br>
<div class="im"><br>
&gt; (3) seems underspecified in the current standard.<br>
<br>
</div>I have yet to use a machine in which s&gt;&gt;n was not implemented<br>
as floor(s/pow(2,n)), but then I&#39;ve been using two&#39;s complement<br>
machines.<br>
<div class="im"><br>
&gt; [I think for consistency we should at least make (3) say that<br>
&gt; bitwise operators on positive operands act as &quot;expected&quot; (that<br>
&gt; is, they give the result that a 2s complement, 1s complement<br>
&gt; or sign-magnitude machine would), and we should make these<br>
&gt; operations on other machines implementation-defined.<br>
<br>
</div>I think we need a definition more specific than &quot;expected&quot;. :)</blockquote><div><br></div><div>The purpose of my &quot;that is...&quot; parenthetical was to informally define what I meant by &quot;expected&quot; =)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im HOEnZb">
&gt; More generally, we should at least say that each integral type<br>
&gt; must be one of 1s complement, 2s complement or sign-magnitude.<br>
&gt; C currently requires this (C99/C11 <a href="http://6.2.6.2/2" target="_blank">6.2.6.2/2</a>), but C++ does not<br>
&gt; (3.9.1/7&#39;s list of representations is not normative and not<br>
&gt; restrictive). 7.2/8 implies that we don&#39;t support other<br>
&gt; representations, but there&#39;s no normative justification for this<br>
&gt; assumption.]<br>
&gt;<br>
&gt; If we require that either (1) or (3) acts as-if 2s complement,<br>
&gt; that actually rules out 1s complement and sign-magnitude<br>
&gt; representations, because these expressions compute a value that<br>
&gt; does not exist in the other representations <a href="tel:%28-2147483648" value="+12147483648">(-2147483648</a> for a<br>
&gt; 32-bit integer):<br>
&gt;<br>
&gt;   int(unsigned(INT_MAX) + 1) // for (1)<br>
&gt;   int(-1 ^ INT_MAX) // for (3)<br>
&gt;<br>
&gt; We could define that (2) acts as-if 2s complement (divide by 2^N<br>
&gt; and round down). I think that&#39;s the least valuable operation to<br>
&gt; define of the three, though.<br>
<br>
</div><span class="HOEnZb"><font color="#888888">--<br>
Lawrence Crowl<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<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" target="_blank">http://www.open-std.org/mailman/listinfo/ub</a><br>
</div></div></blockquote></div><br></div></div>