Bitwise Shift Operator

[Siva Su]

I have a doubt in Left Shift Operator

int i = 1;
i <<= (sizeof (int) *8);
cout << i;

It prints 1.

Doubt:
i has been initialized to 1.
And while moving the bits till the size of the integer, it fills the LSB with 0's and as 1 crosses the limit of integer, i was expecting the output to be 0.

How and Why it is 1?

[Paul McKenzie]

I have a doubt in Left Shift Operator

int i = 1;
i <<= (sizeof (int) *8);
cout << i;

It prints 1.

See the ANSI/ISO C++ standard document, section 5.8:

5.8 Shift operators [expr.shift]
...
The behavior is undefined if the right operand is negative, or
greater than or equal to the length in bits of the promoted left operand.

So you're shifting too many bits, and doing so gives you whatever value you happen to see. It could be 1, it could be 0, or it could be any value.

Regards,

Paul McKenzie

[Eri523]

To get a bit more technical and perhaps clarify the actual observed behavior a bit more: If you did your test on an x86 system, the compiler may well have encoded the actual shift operation as an SHL EAX,32 machine instruction, where the 32-bit int operand has been placed in the 32-bit EAX register beforehand.

And this is an excerpt from the description of this instruction in intel's Pentium&#174; Processor Family Developer’s Manual Volume 3: Architecture and Programming Manual:

The shift is repeated the number of times indicated by the second operand, which is either an immediate number or the contents of the CL register. To reduce the maximum execution time, the Pentium processor does not allow shift counts greater than 31. If a shift count greater than 31 is attempted, only the bottom five bits of the shift count are used. (The 8086 uses all eight bits of the shift count.)

This perfectly would explain the test result you got. However, while that behavior is perfectly deterministic, it is, as pointed out by Paul, undefined according to the C++ standard. That means the behavior of your snippet may be completely different on another architecture, or perhaps even when compiled with a different compiler or compiler options.

On the side note: The small change in behavior of that instruction between CPU generations mentioned by intel (though I wouldn't bet the change actually took place in the transition from the 8086 to the 80186 or 80286, but that's irrelevant here anyway), actually caused a very few existing programs to break that were relying on that behavior detail.