Unexpected results while bit-shifting in C - c

Question

I just hit some unexpected behavior while porting some code. I've boiled it down to this example:
#include <stdint.h>
#include <stdio.h>
uint32_t swap_16_p(uint8_t *value)
{
return (*(uint16_t*)value << 8 | *(uint16_t*)value >> 8);
}
int main()
{
uint8_t start[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xBE, 0xEF };
printf("0x%08x\n", swap_16_p(start));
return 0;
}
On a Little Endian system like x86-64 I would expect this to print 0x0000dead but instead it prints 0x00addead. Looking at the assembly output makes the issue more clear:
uint32_t swap_16_p(uint8_t *value)
{
400506: 55 push %rbp
400507: 48 89 e5 mov %rsp,%rbp
40050a: 48 89 7d f8 mov %rdi,-0x8(%rbp)
return (*(uint16_t*)value << 8 | *(uint16_t*)value >> 8);
40050e: 48 8b 45 f8 mov -0x8(%rbp),%rax
400512: 0f b7 00 movzwl (%rax),%eax
400515: 0f b7 c0 movzwl %ax,%eax
400518: c1 e0 08 shl $0x8,%eax
40051b: 89 c2 mov %eax,%edx
40051d: 48 8b 45 f8 mov -0x8(%rbp),%rax
400521: 0f b7 00 movzwl (%rax),%eax
400524: 66 c1 e8 08 shr $0x8,%ax
400528: 0f b7 c0 movzwl %ax,%eax
40052b: 09 d0 or %edx,%eax
}
40052d: 5d pop %rbp
40052e: c3 retq
By using eax as the scratch area for doing the computation, the extra byte gets shifted past the 16-bit boundary with shl $0x8,%eax. I wouldn't have expected the computation to be treated as a 32-bit value until just before the return (as it would need to promote it to a uint32_t); similar behavior is seen when storing the value in a temporary uint32_t and the printing that instead.
Have I gone against (or improperly interpreted) the C spec, or is this a compiler bug (seems unlikely since this happens in both clang and GCC)?

Answer 1

The integer promotions are done at the "read side", therefore while the expression is evaluated. This means that after reading an integer value that has a smaller size than int resp. unsigned it is immediately converted:
The following may be used in an expression wherever an int or unsigned int may be used:
— An object or expression with an integer type whose integer conversion rank is less than or equal to the rank of int and unsigned int.
— A bit-field of type _Bool, int, signed int, or unsigned int.
If an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions. 48)
48) The integer promotions are applied only: as part of the usual arithmetic conversions, to certain argument expressions, to the operands of the unary +, -, and ~ operators, and to both operands of the shift operators, as specified by their respective subclauses.
ISO/IEC 9899:TC3 6.3.1.1-2
Therefore
*(uint16_t*)value
is immediately converted to int and then shifted.

Answer 2

On a little endian system you are reading a unit16_t memory location that contains value 0xADDE. Before performing shifts, the value is promoted to int type, which is probably 32-bit wide on your platform, producing 0x0000ADDE. Shifts produce 0x00ADDE00 and 0x000000AD respectively. Bitwise OR produces 0x00ADDEAD.
Everything is as expected.
C language does not perform any arithmetic operations within types smaller than int (or unsigned int). Any smaller type is always promoted to int (or unsigned int) before performing the operation. This is what happens with your shifts. Your shifts are int shifts. C does not have "narrower" shifts. C does not have "narrower" additions and multiplications. C does not have "narrower" anything.
If you want a "narrower" shift (or any other operation) you have to simulate it by meticulously manually truncating the intermediate results in order to force them into a smaller type
(uint16_t) (*(uint16_t*) value << 8) | (uint16_t) (*(uint16_t*) value >> 8);
They will constantly spring back to int and you have to constantly beat them back into uint16_t.

Answer 3

This is what the compiler does:
uint32_t swap_16_p(uint8_t *value)
{
uint16_t v1 = *(uint16_t*)value; // -> 0x0000ADDE
int v2 = v1 << 8; // -> 0x00ADDE00
int v3 = v1 >> 8; // -> 0x000000AD
uint32_t v4 = v2 | v3; // -> 0x00ADDEAD
return v4;
}
So the result is well-justified.
Please note that v2 and v3 are results of integral promotion.

Answer 4

Let's look at your logic:
return (*(uint16_t*)value << 8 | *(uint16_t*)value >> 8);
*(uint16_t*)value is 0xADDE since your system is little-endian. (Subject to some caveats which I will mention below).
0xADDE << 8 is 0xADDE00, assuming you have 32-bit (or larger) int. Remember that left-shifting is equivalent to multiplying by a power of 2.
0xADDE >> 8 is 0xAD.
0xADDE00 | 0xAD is 0xADDEAD which is what you observed.
If you expected to 0xDEAD then you are going about it completely the wrong way. Instead the following code would work (and be endian-agnostic):
return (value[0] << 8) | value[1];
although my personal preference, since we are doing arithmetic, is to write it as value[0] * 0x100u + value[1].
*(uint16_t *)value has other problems. Firstly it will cause undefined behaviour if your system has an alignment restriction on integers. Secondly, it violates the strict aliasing rule: objects of type uint8_t may not be read through an lvalue of type uint16_t, again causing undefined behaviour.
If you are porting code that uses aliasing casts like this, I'd suggest disabling type-based aliasing optimization in your compiler until you fully understand the issues. In gcc the flag is -fno-strict-aliasing.