Answer: B
Correct answer: 64 32, 0 32, 16 32, 0 32
Take the four lines in turn, remembering that << shifts the bits left, multiplying by a power of two, and >> shifts right, dividing by one.
32<<1 doubles 32 to 64, and 32<<0 shifts by nothing, leaving 32. First line: 64 32.
The third line is the mirror image: 32>>1 halves 32 to 16, and 32>>0 leaves 32. Third line: 16 32.
The second and fourth lines are the interesting ones. -0 is simply 0 in two’s complement - there is no negative zero for integers - so 32<<-0 and 32>>-0 are shifts by zero and give 32. A shift by -1, however, is undefined behaviour: the standard says the result is undefined when the right operand is negative or not less than the width of the promoted left operand. In practice the x86 shift instructions mask the count to its low five bits, so -1 becomes 31; 32<<31 overflows a 32-bit int to 0, and 32>>31 shifts every set bit off the right-hand end, also giving 0. Second and fourth lines: 0 32.
The output is therefore 64 32, 0 32, 16 32, 0 32. It is worth being clear that only the first and third lines are guaranteed by the language; the zeros on the other two are what a typical compiler on this hardware produces, not what the standard promises, and a compiler is free to emit anything at all for them. This record had lost two of the four printf lines to a stray < in the stored HTML; they are restored above, which is what makes the keyed sequence of eight numbers legible.