<div dir="ltr">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.<div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 17, 2014 at 11:59 AM, 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">Or require implementations to tell you programmatically what they are using as binary representation:<br>
<br>
    enum class binary_system {<br>
          other,<br>
          sign_magnitude,<br>
          ones_complement,<br>
          twos_complement<br>
    };<br>
<br>
    template&lt;BuiltinIntegralType T&gt;<br>
          constexpr binary_system encoding = /* implementation defined */<br>
<br>
-- Gaby<br>
<span class="im HOEnZb"><br>
| -----Original Message-----<br>
| From: <a href="mailto:ub-bounces@open-std.org" class="cremed">ub-bounces@open-std.org</a> [mailto:<a href="mailto:ub-bounces@open-std.org" class="cremed">ub-bounces@open-std.org</a>] On<br>
| Behalf Of Jeffrey Yasskin<br>
| Sent: Monday, November 17, 2014 11:11 AM<br>
| To: WG21 UB study group<br>
| Subject: Re: [ub] Signed shifting<br>
|<br>
</span><div class="HOEnZb"><div class="h5">| * 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" 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  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.  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" 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" 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" 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>
</div></div></blockquote></div><br></div></div></div></div></div>