Hacker News Reader

Comment by kevincox | Hacker News Reader

If you write it the naive way it works.

    uint8_t bytes[4];
    uint32_t = bytes[0] << 24 + bytes[1] << 16 + bytes[2] << 8 + bytes[3];

The endianness is whatever you write in the indexing and will be the same across architectures.

View on HN

Unfortunately, the naive way also turns out to be wrong in C. uint8_t gets promoted to a signed int when shifting, which in turn causes undefined behavior for specific input. One way of fixing this is casting to the desired type before the shift, thus avoiding surprising conversions.

On a side note, compiler warnings and sanitizers help with this kind of stuff greatly, use them if you have the option: https://godbolt.org/z/8oq9GTcze

>> uint8_t gets promoted to a signed int when shifting, which in turn causes undefined behavior for specific input. >> One way of fixing this is casting to the desired type before the shift, thus avoiding surprising conversions.

Agree. For clarity, the "specific input" in the example would be a bytes[0] value larger than 127.

This behavior is also explained here:

https://wiki.sei.cmu.edu/confluence/display/c/INT34-C.+Do+no...

Reply on news.ycombinator.com