Why does 1ul << 64 return 1 instead of 0?

Question

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?

To start with you're using the wrong format to print an `unsigned long` value. You should be using `"%lu"`. See e.g. [this `printf` (and family) reference](http://en.cppreference.com/w/c/io/fprintf). — Some programmer dude, May 04 '16 at 04:31
@JonnyHenly If I just do `int i = 64` and do the shift and print, it gives 0. Isn't it magical? — OneZero, May 04 '16 at 04:31
Undefined behaviour can do anything it likes and it is correct! In this case, it is likely that the shift size is reduced modulo 64 to be equivalent to `1UL << 0` which is 1. You could look at the assembler to see whether that's correct for your compiler — but the behaviour varies between machines and compilers, and is (I emphasize) undefined behaviour so any result is correct. The difference is likely the result of compile-time vs run-time evaluation of the expression. — Jonathan Leffler, May 04 '16 at 04:32
@JoachimPileborg I don't think the format is an issue here. Since it doesn't matter what format we put, the bit shifting produces either 000...000 or 000...001, so even with the wrong print format, only leftmost zeros will be truncated. The value, 0 or 1, would not be affected. — OneZero, May 04 '16 at 04:33
I think there are two issues here: (1) The format is incorrect, so it could easily be printing garbage (just fix the bug instead of speculating about it), and (2) I believe the shift result is undefined (assuming `unsigned long` is 64 bits or less). I believe shifts amounts must be in the range 0 through one less than the number of bits. — Tom Karzes, May 04 '16 at 04:36
No not in this case, but otherwise on systems where `sizeof(long) != sizeof(int)` you could get wrong results. — Some programmer dude, May 04 '16 at 04:36

score 8 · Accepted Answer · edited May 23 '17 at 11:54

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.

Why does 1ul << 64 return 1 instead of 0?

1 Answers1

Linked