Left Bit shift and casting

I have a behaviour that i don't understand, i try to construct an 64 integer from an array of bytes from big endian to little endian.

uint64_t u;
uint8_t bytes[2];


bytes[1] = 0xFF;
u =  bytes[1] << 24 ;
dump_bytes_as_hex( &u, 8 );

00 00 00 FF FF FF FF FF

u =  ( (uint16_t) bytes[1]) << 24 ;
dump_bytes_as_hex( &u, 8 );

00 00 00 FF FF FF FF FF

u =  ( (uint32_t) bytes[1]) << 24 ;
dump_bytes_as_hex( &u, 8 );

00 00 00 FF 00 00 00 00

I don't understand why it give me the correct result only if i cast to a type that has more bits than the shift size. I have tried different values :

• 0xFF-1 give the same bad result
• 100 give correct result without casting

So i wanted to know what is the rule ? and why 100 give me the correct value.

Thank you.

Edit :

Here is a reproductible example :

#include <stdio.h>
#include <stdint.h>


void dump_bytes_as_hex( uint8_t* b, int count )
{
    FILE* f;

    f = stdout;

    for( int c = 0; c < count; ++c )
    {
        fprintf( f, "%02X", b[c] );
        fputc( ' ', f );
    }
    fputc( '\n', f );
    fflush( f );
}

void test( uint8_t i )
{
    uint64_t u;
    uint8_t bytes[2];

    fprintf( stdout, "Test with %d\n", (int) i );

    u = 0;
    bytes[1] = i;

    u =  bytes[1] << 24 ;
    dump_bytes_as_hex( (uint8_t*) &u, 8 );

    u =  ( (uint16_t) bytes[1]) << 24 ;
    dump_bytes_as_hex( (uint8_t*) &u, 8 );

    u =  ( (uint32_t) bytes[1]) << 24 ;
    dump_bytes_as_hex( (uint8_t*) &u, 8 );

    fprintf( stdout, "\n\n");
}



int main()
{

    test( 0xFF );
    test( 0xFF -1  );
    test( 100 );

    return 0;

}

The type of the variable to which you assign the result, if any, is irrelevant.

It only works if the type of the left-hand operand is a type that, after integer promotion, can hold the result.

• (uint8_t)0xFF << 24

  In an environment with an int type of 16..32 bits, (uint8_t)0xFF is promoted to an int. 0xFF × 2²⁴ is too large to hold in an int. Being a signed type, this results in undefined behaviour.

  In an environment with an int type of 33+ bits, (uint8_t)0xFF is promoted to an int. 0xFF × 2²⁴ fits in an int. This works.

• (uint16_t)0xFF << 24

  In an environment with an int type of 16..24 bits, (uint16_t)0xFF results in a 16-bit unsigned int. Left-shifting by an amount of bits greater than or equal to the size of the operand is undefined behaviour.

  In an environment with an int type of 25..32 bits, (uint16_t)0xFF results in an int. 0xFF × 2²⁴ is too large to hold in an int. Being a signed type, this results in undefined behaviour.

  In an environment with an int type of 33+ bits, (uint16_t)0xFF results in an int. 0xFF × 2²⁴ fits in an int. This works.

• (uint32_t)0xFF << 24

  0xFF × 2²⁴ fits in a 32-bit unsigned integer. This works.

So, to produce a uint64_t, you want

(uint64_t)( (uint64_t)u8 << 24 )

or

(uint64_t)( (uint32_t)u8 << 24 )

However, the outer cast can be dropped here since the assignment will implicitly perform this cast.

> So i wanted to know what is the rule ?

In fact there is no rule for your specific examples ...

> bytes[1] = 0xFF;
> u = bytes[1] << 24 ;

... and ...

> u = ( (uint16_t) bytes[1]) << 24 ;
> dump_bytes_as_hex( &u, 8 );

... in the event that your int is 32 bits wide.

The left operand of a shift operation is is subject to the usual arithmetic conversions, which will have the effect of converting the 8- or 16-bit unsigned value of the left operand to (signed) int and producing a result of that type. If the arithmetic result of a left shift of a value of signed type (i.e. int) is not representable as a value of that type then the behavior is undefined. That is the case here (which is why I said there is no rule).

In your particular case, it appears that your implementation is performing the shift as if by reinterpreting the left operand as an unsigned 32-bit value, the reinterpreting the result as a (signed) int. The assignment to type uint64_t then proceeds (normally) by converting the negative right operand to ty uint64_t by adding 2⁶⁴ to bring it into the range of that type. (Such conversions are performed only for conversion to unsigned integer types, not to signed ones.) You are working on a little-endian system and printing out the resulting bytes in memory order, so you get:

> 00 00 00 FF FF FF FF FF

On the other hand, if you convert the shift operand to uint32_t on your 32-0bit system, ...

> u = ( (uint32_t) bytes[1]) << 24 ;
> dump_bytes_as_hex( &u, 8 );

... then the resulting type is unaffected by the standard arithmetic conversions, and the result of the conversion has that type. uint32_t can represent the arithmetic result of the shift (0xff000000), so that is in fact the result. That value is unchanged when converted to type uint64_t for the assignment.

General advice: use unsigned types when working with bitwise operations, and especially when performing shifts.