Date: Mon, 17 Nov 2014 19:59:32 +0000
Or require implementations to tell you programmatically what they are using as binary representation:
enum class binary_system {
other,
sign_magnitude,
ones_complement,
twos_complement
};
template<BuiltinIntegralType T>
constexpr binary_system encoding = /* implementation defined */
 Gaby
 Original Message
 From: ubbounces_at_[hidden] [mailto:ubbounces_at_[hidden]] On
 Behalf Of Jeffrey Yasskin
 Sent: Monday, November 17, 2014 11:11 AM
 To: WG21 UB study group
 Subject: Re: [ub] Signed shifting

 * The last thread on two'scomplement representation managed to find
 one modern Unisys system that uses one'scomplement, and the thread
 reported that this one supports Java, so it has to have a way to
 execute two'scomplement shifts. We shouldn't be building a standard
 for imaginary systems.

 * Even if 'int' needs to support nontwo'scomplement, the referenced
 code
 (https://github.com/teor2345/tor/blob/ced74e0144e967f838416e6af92cba6
 5c007d89b/src/ext/curve25519_donna/curve25519donna.c#L56)
 uses int64_t, which <C99 7.18.1.1 Exactwidth integer types> says is
 already two's complement. C++14 defers to C99 for this. We could
 define shifts on two's complement types that would stay
 implementationdefined on anything else.

 * Programmers are used to writing "X << N" to mean "X * 2^N". Without
 a good reason, we shouldn't make them use worse syntax for this, even
 for signed numbers. "Applying [bitshifts] to signed numbers is a bug"
 is just incorrect given compilers' and hardware's actual behavior.
 (Appealing to the fact that it's undefined behavior in the current
 standard is just begging the question.)

 * If we wanted to provide a library function to represent shifting,
 I'm having trouble coming up with a good name for it. A free library
 function operating on integers is terrible: times_two_to_the(X, N)? A
 member function for the constanttime class that competes with "<< N"
 is also hard to produce: X.times_two_to_the(N)? X.times_pow2(N)? The
 main objection to the constanttime library in LEWG was that we
 weren't sure anyone would use it. Insisting that folks switch from
 operators to functions would increase that risk.

 Jeffrey

 On Sat, Nov 15, 2014 at 9:15 AM, Jens Maurer <Jens.Maurer_at_[hidden]>
 wrote:
 >
 > A preliminary observation: The C++ standard (in contrast to the C
 > standard) does not explicitly prescribe one of two's complement,
 > one's complement, signmagnitude for signed integer representations,
 > but certainly those three choices are allowed by C++.
 >
 > On 11/14/2014 11:45 PM, Jeffrey Yasskin wrote:
 >> We could suggest that the programmers explicitly multiply by a power
 >> of 2 instead, but they're using the <<s at least partly to get
 >> constanttime operation, and relying on multiplication for this would
 >> depend even more on implementation details than they already are.
 >
 > This seems to rely on two's complement representation for negative
 > numbers, which is (from the standard's perspective) a nonportable
 > assumption.
 >
 > In my opinion, users expecting constanttime operations would be
 > better served with a (small) library that allows them to express their
 > intent, instead of misusing shifts for multiplication. For example,
 > the following would help (after adding a "multiplicationbypoweroftwo"
 > function):
 > http://www.openstd.org/jtc1/sc22/wg21/docs/papers/2014/n4145.html
 >
 >> Separately, a related piece of code uses a signed rightshift to
 >> repeat the sign bit across all the bits of a number:
 >>
 https://boringssl.googlesource.com/boringssl/+/e18d821dfcc32532caeeb1a2
 d15090672f592ce3/crypto/internal.h#157.
 >> This is implementationdefined rather than undefined, so the
 >> programmers can probably use #if to check for the behavior they
 >> expect, as at
 >>
 https://github.com/teor2345/tor/blob/ced74e0144e967f838416e6af92cba65
 c007d89b/src/ext/curve25519_donna/curve25519donna.c#L466
 >
 > Well, that's still a bit disappointing, since you get an #error if your
 > compiler doesn't provide the expected semantics.
 >
 > If we can identify a small set of basic operations that people want to
 > use, we should give them a (small) library instead of asking them to do
 > nonportable things.
 >
 >> Is there space to improve the situation here?
 >
 > Yes, but (in my opinion), it's not in the direction of changing the
 > core language for these purposes.
 >
 > Bitshifts are for unsigned numbers; applying them to signed numbers
 > is a bug, in my opinion.
 >
 > Jens
 > _______________________________________________
 > ub mailing list
 > ub_at_[hidden]
 > http://www.openstd.org/mailman/listinfo/ub
 _______________________________________________
 ub mailing list
 ub_at_[hidden]
 http://www.openstd.org/mailman/listinfo/ub
enum class binary_system {
other,
sign_magnitude,
ones_complement,
twos_complement
};
template<BuiltinIntegralType T>
constexpr binary_system encoding = /* implementation defined */
 Gaby
 Original Message
 From: ubbounces_at_[hidden] [mailto:ubbounces_at_[hidden]] On
 Behalf Of Jeffrey Yasskin
 Sent: Monday, November 17, 2014 11:11 AM
 To: WG21 UB study group
 Subject: Re: [ub] Signed shifting

 * The last thread on two'scomplement representation managed to find
 one modern Unisys system that uses one'scomplement, and the thread
 reported that this one supports Java, so it has to have a way to
 execute two'scomplement shifts. We shouldn't be building a standard
 for imaginary systems.

 * Even if 'int' needs to support nontwo'scomplement, the referenced
 code
 (https://github.com/teor2345/tor/blob/ced74e0144e967f838416e6af92cba6
 5c007d89b/src/ext/curve25519_donna/curve25519donna.c#L56)
 uses int64_t, which <C99 7.18.1.1 Exactwidth integer types> says is
 already two's complement. C++14 defers to C99 for this. We could
 define shifts on two's complement types that would stay
 implementationdefined on anything else.

 * Programmers are used to writing "X << N" to mean "X * 2^N". Without
 a good reason, we shouldn't make them use worse syntax for this, even
 for signed numbers. "Applying [bitshifts] to signed numbers is a bug"
 is just incorrect given compilers' and hardware's actual behavior.
 (Appealing to the fact that it's undefined behavior in the current
 standard is just begging the question.)

 * If we wanted to provide a library function to represent shifting,
 I'm having trouble coming up with a good name for it. A free library
 function operating on integers is terrible: times_two_to_the(X, N)? A
 member function for the constanttime class that competes with "<< N"
 is also hard to produce: X.times_two_to_the(N)? X.times_pow2(N)? The
 main objection to the constanttime library in LEWG was that we
 weren't sure anyone would use it. Insisting that folks switch from
 operators to functions would increase that risk.

 Jeffrey

 On Sat, Nov 15, 2014 at 9:15 AM, Jens Maurer <Jens.Maurer_at_[hidden]>
 wrote:
 >
 > A preliminary observation: The C++ standard (in contrast to the C
 > standard) does not explicitly prescribe one of two's complement,
 > one's complement, signmagnitude for signed integer representations,
 > but certainly those three choices are allowed by C++.
 >
 > On 11/14/2014 11:45 PM, Jeffrey Yasskin wrote:
 >> We could suggest that the programmers explicitly multiply by a power
 >> of 2 instead, but they're using the <<s at least partly to get
 >> constanttime operation, and relying on multiplication for this would
 >> depend even more on implementation details than they already are.
 >
 > This seems to rely on two's complement representation for negative
 > numbers, which is (from the standard's perspective) a nonportable
 > assumption.
 >
 > In my opinion, users expecting constanttime operations would be
 > better served with a (small) library that allows them to express their
 > intent, instead of misusing shifts for multiplication. For example,
 > the following would help (after adding a "multiplicationbypoweroftwo"
 > function):
 > http://www.openstd.org/jtc1/sc22/wg21/docs/papers/2014/n4145.html
 >
 >> Separately, a related piece of code uses a signed rightshift to
 >> repeat the sign bit across all the bits of a number:
 >>
 https://boringssl.googlesource.com/boringssl/+/e18d821dfcc32532caeeb1a2
 d15090672f592ce3/crypto/internal.h#157.
 >> This is implementationdefined rather than undefined, so the
 >> programmers can probably use #if to check for the behavior they
 >> expect, as at
 >>
 https://github.com/teor2345/tor/blob/ced74e0144e967f838416e6af92cba65
 c007d89b/src/ext/curve25519_donna/curve25519donna.c#L466
 >
 > Well, that's still a bit disappointing, since you get an #error if your
 > compiler doesn't provide the expected semantics.
 >
 > If we can identify a small set of basic operations that people want to
 > use, we should give them a (small) library instead of asking them to do
 > nonportable things.
 >
 >> Is there space to improve the situation here?
 >
 > Yes, but (in my opinion), it's not in the direction of changing the
 > core language for these purposes.
 >
 > Bitshifts are for unsigned numbers; applying them to signed numbers
 > is a bug, in my opinion.
 >
 > Jens
 > _______________________________________________
 > ub mailing list
 > ub_at_[hidden]
 > http://www.openstd.org/mailman/listinfo/ub
 _______________________________________________
 ub mailing list
 ub_at_[hidden]
 http://www.openstd.org/mailman/listinfo/ub
Received on 20141117 21:15:09