问题
Consider the following piece of code:
// Simply loop over until 64 is hit.
unsigned long x = 0;
for (int i = 0; i <= 64; i++) {
if (i == 64) {
x = 1ul << i;
printf("x: %d\n", x);
}
}
We know that unsigned long is 64-bit wide, and left shifting 1 by 64 positions would become 1000...000 (64 zeros behind one), and would have been truncated to 0. However, the actual printout gives:
x: 1
The strange thing is, if we just do
printf("x: %d\n", (1ul << 64));
It would print 0.
Can anyone explain why this is happening? Why in the first case, the program mistakenly produces 1 instead of 0, but in the second case it's correct?
回答1:
Shifting by the width of a type or more causes undefined behaviour according to §6.5.7/3:
- The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand. If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined.
The rationale for this is that various CPUs implement different behaviour for over-sized shifts and it would have been too restrictive to define behaviour for this case -- many shifts would need extra assembly generated. (Although perhaps it should have been implementation-defined rather than undefined).
Your observation could be explained by using Intel family CPU which in hardware does "mod 64" on the shift width for a 64-bit type, so at runtime 1ul << 64 did the same as 1ul << 0 would; but at compile-time in the other case the compiler computed 1ul << 64 using arithmetic rules.
来源：https://stackoverflow.com/questions/37018469/why-does-1ul-64-return-1-instead-of-0