Right shift and signed integer

Question

On my compiler, the following pseudo code (values replaced with binary):

sint32 word = (10000000 00000000 00000000 00000000);
word >>= 16;

produces a word with a bitfield that looks like this:

(11111111 11111111 10000000 00000000)

My question is, can I rely on this behaviour for all platforms and C++ compilers?

score 31 · Accepted Answer · edited Feb 15 '15 at 18:21

31

From the following link:
INT34-C. Do not shift an expression by a negative number of bits or by greater than or equal to the number of bits that exist in the operand

Noncompliant Code Example (Right Shift)
The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a nonnegative value, the value of the result is the integral part of the quotient of E1 / 2^E2. If E1 has a signed type and a negative value, the resulting value is implementation defined and can be either an arithmetic (signed) shift:

or a logical (unsigned) shift:

This noncompliant code example fails to test whether the right operand is greater than or equal to the width of the promoted left operand, allowing undefined behavior.

unsigned int ui1;
unsigned int ui2;
unsigned int uresult;

/* Initialize ui1 and ui2 */

uresult = ui1 >> ui2;

Making assumptions about whether a right shift is implemented as an arithmetic (signed) shift or a logical (unsigned) shift can also lead to vulnerabilities. See recommendation INT13-C. Use bitwise operators only on unsigned operands.

edited Feb 15 '15 at 18:21

Ben Voigt

269,602
39
394
697

answered Sep 22 '11 at 23:05

Andrew Clark

192,132
30
260
294

2

Was there no recommendation that actually focused on this issue? Because based on the name of that rule, it doesn't apply here... you're just quoting some of the provided background information. – Ben Voigt Feb 15 '15 at 18:22
The 2nd, more relevant link has moved. The new link is https://wiki.sei.cmu.edu/confluence/display/c/INT13-C.+Use+bitwise+operators+only+on+unsigned+operands – underscore_d Oct 29 '18 at 20:14
1

If the amount you are shifting is a compile-time constant, you can force an arithmetic shift by using (signed) division instead. Thus, instead of 'a >> 16', which is implementation defined, you'd write 'a / (1 << 16)' which the compiler will almost certainly replace with an arithmetic shift. – Pablo Halpern Jan 21 '20 at 19:48

score 19 · Answer 2 · answered Feb 01 '19 at 15:52

19

From the latest C++20 draft:

Right-shift on signed integral types is an arithmetic right shift, which performs sign-extension.

answered Feb 01 '19 at 15:52

Wait! Does that mean all signed values are required to use 2s complement? – Adrian Jun 23 '19 at 08:27
2

@Adrian [Yes](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1236r1.html). – Jun 24 '19 at 23:35

score 14 · Answer 3 · answered Sep 22 '11 at 22:51

14

No, you can't rely on this behaviour. Right shifting of negative quantities (which I assume your example is dealing with) is implementation defined.

answered Sep 22 '11 at 22:51

R. Martinho Fernandes

219,040
71
423
503

Okay, that's fair. I still wonder though, if the compiler creates a binary that does use this method, would it work as expected across most hardware at least? – Anne Quinn Sep 22 '11 at 22:58
5

If you compile something for a certain architecture, that's supposed to work the same across all implementations of that architecture. x86, for example, has different shift operations for sign-extension and non-sign-extension shifts, and it's the compiler that decides which one to use. It probably won't work at all (read: *anything at all*, not just this behaviour) on other architectures. – R. Martinho Fernandes Sep 22 '11 at 23:01

score 7 · Answer 4 · answered Sep 23 '11 at 06:55

In C++, no. It is implementation and/or platform dependent.

In some other languages, yes. In Java, for example, the >> operator is precisely defined to always fill using the left most bit (thereby preserving sign). The >>> operator fills using 0s. So if you want reliable behavior, one possible option would be to change to a different language. (Although obviously, this may not be an option depending on your circumstances.)

score 3 · Answer 5 · answered Sep 22 '11 at 22:53

3

AFAIK integers may be represented as sign-magnitude in c++, in which case sign extension would fill with 0s. So you can't rely on this.

answered Sep 22 '11 at 22:53

CodesInChaos

103,479
23
206
257

You're right. The standard makes some requirements that make two's complement the optimal representation, but in general, signed integers can be represented in any way the implementation wants. – R. Martinho Fernandes Sep 22 '11 at 22:56

Right shift and signed integer

5 Answers5

Linked

Related