<div dir="ltr">+1. I&#39;m sympathetic to the strength of Howard&#39;s opinion, and it&#39;d be great to remove the complication of needing to check for unexpected integer formats, but I&#39;d be really happy to get just the check if that&#39;s all we can agree on.<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 17, 2014 at 12:57 PM, Gabriel Dos Reis <span dir="ltr">&lt;<a href="mailto:gdr@microsoft.com" target="_blank" class="cremed">gdr@microsoft.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-family:&quot;Calisto MT&quot;,serif;color:#7030a0">Agreed, and that is the easier part :-)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:&quot;Calisto MT&quot;,serif;color:#7030a0"><u></u>&nbsp;<u></u></span></p>
<p class="MsoNormal"><span style="font-family:&quot;Calisto MT&quot;,serif;color:#7030a0">I&rsquo;m trying to find a middle-ground for people to get certainty (the implementation will tell you programmatically what the encoding is), while removing or reducing the surface area
 of undefined behavior.&nbsp; My suspicion is that we will end up with 2&rsquo;s complement for most cases.&nbsp; But that is not based on a scientific study.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:&quot;Calisto MT&quot;,serif;color:#7030a0"><u></u>&nbsp;<u></u></span></p>
<p class="MsoNormal"><span style="font-family:&quot;Calisto MT&quot;,serif;color:#7030a0">-- Gaby<u></u><u></u></span></p>
<p class="MsoNormal"><a name="149bf8bf80dada72__MailEndCompose" class="cremed"><span style="font-family:&quot;Calisto MT&quot;,serif;color:#7030a0"><u></u>&nbsp;<u></u></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif"> <a href="mailto:ub-bounces@open-std.org" target="_blank" class="cremed">ub-bounces@open-std.org</a> [mailto:<a href="mailto:ub-bounces@open-std.org" target="_blank" class="cremed">ub-bounces@open-std.org</a>]
<b>On Behalf Of </b>Jeffrey Yasskin<br>
<b>Sent:</b> Monday, November 17, 2014 12:32 PM</span></p><div><div class="h5"><br>
<b>To:</b> WG21 UB study group<br>
<b>Subject:</b> Re: [ub] Signed shifting<u></u><u></u></div></div><p></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u>&nbsp;<u></u></p>
<div>
<p class="MsoNormal">We&#39;d still need to define the behavior of signed shifting when encoding&lt;T&gt;==binary_system::twos_complement, for it to help this use case.<u></u><u></u></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><u></u>&nbsp;<u></u></p>
<div>
<p class="MsoNormal">On Mon, Nov 17, 2014 at 11:59 AM, Gabriel Dos Reis &lt;<a href="mailto:gdr@microsoft.com" target="_blank" class="cremed">gdr@microsoft.com</a>&gt; wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Or require implementations to tell you programmatically what they are using as binary representation:<br>
<br>
&nbsp; &nbsp; enum class binary_system {<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; other,<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; sign_magnitude,<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ones_complement,<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; twos_complement<br>
&nbsp; &nbsp; };<br>
<br>
&nbsp; &nbsp; template&lt;BuiltinIntegralType T&gt;<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; constexpr binary_system encoding = /* implementation defined */<br>
<br>
-- Gaby<br>
<br>
<span>| -----Original Message-----</span><br>
<span>| From: <a href="mailto:ub-bounces@open-std.org" target="_blank" class="cremed">ub-bounces@open-std.org</a> [mailto:<a href="mailto:ub-bounces@open-std.org" target="_blank" class="cremed">ub-bounces@open-std.org</a>] On</span><br>
<span>| Behalf Of Jeffrey Yasskin</span><br>
<span>| Sent: Monday, November 17, 2014 11:11 AM</span><br>
<span>| To: WG21 UB study group</span><br>
<span>| Subject: Re: [ub] Signed shifting</span><br>
<span>|</span><u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">| * The last thread on two&#39;s-complement representation managed to find<br>
| one modern Unisys system that uses one&#39;s-complement, and the thread<br>
| reported that this one supports Java, so it has to have a way to<br>
| execute two&#39;s-complement shifts. We shouldn&#39;t be building a standard<br>
| for imaginary systems.<br>
|<br>
| * Even if &#39;int&#39; needs to support non-two&#39;s-complement, the referenced<br>
| code<br>
| (<a href="https://github.com/teor2345/tor/blob/ced74e0144e967f838416e6af92cba6" target="_blank" class="cremed">https://github.com/teor2345/tor/blob/ced74e0144e967f838416e6af92cba6</a><br>
| 5c007d89b/src/ext/curve25519_donna/curve25519-donna.c#L56)<br>
| uses int64_t, which &lt;C99 7.18.1.1 Exact-width integer types&gt; says is<br>
| already two&#39;s complement. C++14 defers to C99 for this. We could<br>
| define shifts on two&#39;s complement types that would stay<br>
| implementation-defined on anything else.<br>
|<br>
| * Programmers are used to writing &quot;X &lt;&lt; N&quot; to mean &quot;X * 2^N&quot;. Without<br>
| a good reason, we shouldn&#39;t make them use worse syntax for this, even<br>
| for signed numbers. &quot;Applying [bit-shifts] to signed numbers is a bug&quot;<br>
| is just incorrect given compilers&#39; and hardware&#39;s actual behavior.<br>
| (Appealing to the fact that it&#39;s undefined behavior in the current<br>
| standard is just begging the question.)<br>
|<br>
| * If we wanted to provide a library function to represent shifting,<br>
| I&#39;m having trouble coming up with a good name for it. A free library<br>
| function operating on integers is terrible: times_two_to_the(X, N)? A<br>
| member function for the constant-time class that competes with &quot;&lt;&lt; N&quot;<br>
| is also hard to produce: X.times_two_to_the(N)? X.times_pow2(N)? The<br>
| main objection to the constant-time library in LEWG was that we<br>
| weren&#39;t sure anyone would use it. Insisting that folks switch from<br>
| operators to functions would increase that risk.<br>
|<br>
| Jeffrey<br>
|<br>
| On Sat, Nov 15, 2014 at 9:15 AM, Jens Maurer &lt;<a href="mailto:Jens.Maurer@gmx.net" target="_blank" class="cremed">Jens.Maurer@gmx.net</a>&gt;<br>
| wrote:<br>
| &gt;<br>
| &gt; A preliminary observation: The C++ standard (in contrast to the C<br>
| &gt; standard) does not explicitly prescribe one of&nbsp; two&#39;s complement,<br>
| &gt; one&#39;s complement, sign-magnitude for signed integer representations,<br>
| &gt; but certainly those three choices are allowed by C++.<br>
| &gt;<br>
| &gt; On 11/14/2014 11:45 PM, Jeffrey Yasskin wrote:<br>
| &gt;&gt; We could suggest that the programmers explicitly multiply by a power<br>
| &gt;&gt; of 2 instead, but they&#39;re using the &lt;&lt;s at least partly to get<br>
| &gt;&gt; constant-time operation, and relying on multiplication for this would<br>
| &gt;&gt; depend even more on implementation details than they already are.<br>
| &gt;<br>
| &gt; This seems to rely on two&#39;s complement representation for negative<br>
| &gt; numbers, which is (from the standard&#39;s perspective) a non-portable<br>
| &gt; assumption.<br>
| &gt;<br>
| &gt; In my opinion, users expecting constant-time operations would be<br>
| &gt; better served with a (small) library that allows them to express their<br>
| &gt; intent, instead of misusing shifts for multiplication.&nbsp; For example,<br>
| &gt; the following would help (after adding a &quot;multiplication-by-power-of-two&quot;<br>
| &gt; function):<br>
| &gt; <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4145.html" target="_blank" class="cremed">
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4145.html</a><br>
| &gt;<br>
| &gt;&gt; Separately, a related piece of code uses a signed right-shift to<br>
| &gt;&gt; repeat the sign bit across all the bits of a number:<br>
| &gt;&gt;<br>
| <a href="https://boringssl.googlesource.com/boringssl/+/e18d821dfcc32532caeeb1a2" target="_blank" class="cremed">
https://boringssl.googlesource.com/boringssl/+/e18d821dfcc32532caeeb1a2</a><br>
| d15090672f592ce3/crypto/internal.h#157.<br>
| &gt;&gt; This is implementation-defined rather than undefined, so the<br>
| &gt;&gt; programmers can probably use #if to check for the behavior they<br>
| &gt;&gt; expect, as at<br>
| &gt;&gt;<br>
| <a href="https://github.com/teor2345/tor/blob/ced74e0144e967f838416e6af92cba65" target="_blank" class="cremed">
https://github.com/teor2345/tor/blob/ced74e0144e967f838416e6af92cba65</a><br>
| c007d89b/src/ext/curve25519_donna/curve25519-donna.c#L466<br>
| &gt;<br>
| &gt; Well, that&#39;s still a bit disappointing, since you get an #error if your<br>
| &gt; compiler doesn&#39;t provide the expected semantics.<br>
| &gt;<br>
| &gt; If we can identify a small set of basic operations that people want to<br>
| &gt; use, we should give them a (small) library instead of asking them to do<br>
| &gt; non-portable things.<br>
| &gt;<br>
| &gt;&gt; Is there space to improve the situation here?<br>
| &gt;<br>
| &gt; Yes, but (in my opinion), it&#39;s not in the direction of changing the<br>
| &gt; core language for these purposes.<br>
| &gt;<br>
| &gt; Bit-shifts are for unsigned numbers; applying them to signed numbers<br>
| &gt; is a bug, in my opinion.<br>
| &gt;<br>
| &gt; Jens<br>
| &gt; _______________________________________________<br>
| &gt; ub mailing list<br>
| &gt; <a href="mailto:ub@isocpp.open-std.org" target="_blank" class="cremed">ub@isocpp.open-std.org</a><br>
| &gt; <a href="http://www.open-std.org/mailman/listinfo/ub" target="_blank" class="cremed">http://www.open-std.org/mailman/listinfo/ub</a><br>
| _______________________________________________<br>
| ub mailing list<br>
| <a href="mailto:ub@isocpp.open-std.org" target="_blank" class="cremed">ub@isocpp.open-std.org</a><br>
| <a href="http://www.open-std.org/mailman/listinfo/ub" target="_blank" class="cremed">http://www.open-std.org/mailman/listinfo/ub</a><br>
_______________________________________________<br>
ub mailing list<br>
<a href="mailto:ub@isocpp.open-std.org" target="_blank" class="cremed">ub@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/ub" target="_blank" class="cremed">http://www.open-std.org/mailman/listinfo/ub</a><u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u>&nbsp;<u></u></p>
</div>
</div>
</div>
</div>
</div>
</div></div></div>
</div>
</div>

<br>_______________________________________________<br>
ub mailing list<br>
<a href="mailto:ub@isocpp.open-std.org" class="cremed">ub@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/ub" target="_blank" class="cremed">http://www.open-std.org/mailman/listinfo/ub</a><br>
<br></blockquote></div><br></div></div>