Careful about that one. I believe `uint8_t` isn't required to be a character type, which has implications for type based aliasing.
The fact that every single compiler typedefs "uint8_t" and "unsigned char" and yet that isn't guaranteed by the standard is the kind of thing that just makes you want to cry.
I'm actually genuinely curious about this: people talk about the possibility of existence, but I haven't seen anybody point to an actual compiler that implements uint8_t as an extended numeric type rather than being an equivalent typedef to "unsigned char". Is there a compiler that really does this?
> The fact that every single compiler typedefs "uint8_t" and "unsigned char" [...] and yet that isn't guaranteed by the standard
They don't. The standard is right on this. It's supposed to let authors know what can be relied on portably on real C/C++ systems in use. (Targets where char is not even 8 bits might make you cry even more, but I think those are legitimately obscure now.)
> Is there a compiler that really does this?
Here's a popular one with hobbyists in 2022. The definition of uint8_t in the Arduino system header files is not "unsigned char". I have seen this definition used elsewhere too:
typedef unsigned int uint8_t __attribute__((__mode__(__QI__)));
A few tests on generated code, however, suggest that gcc treats these
exactly as signed char and unsigned char, both in how the react to
_Generic and in how the compiler handles them for alias analysis.
So, that means that there are currently zero existing compilers that treat uint8_t differently from unsigned char.
Pretty sure I remember a GCC bug that amounted to uint8_t behaving differently to unsigned char wrt aliasing. It's the sort of thing I'd expect clang to do too.
Comments
The fact that every single compiler typedefs "uint8_t" and "unsigned char" and yet that isn't guaranteed by the standard is the kind of thing that just makes you want to cry.
I'm actually genuinely curious about this: people talk about the possibility of existence, but I haven't seen anybody point to an actual compiler that implements uint8_t as an extended numeric type rather than being an equivalent typedef to "unsigned char". Is there a compiler that really does this?
> The fact that every single compiler typedefs "uint8_t" and "unsigned char" [...] and yet that isn't guaranteed by the standard
They don't. The standard is right on this. It's supposed to let authors know what can be relied on portably on real C/C++ systems in use. (Targets where char is not even 8 bits might make you cry even more, but I think those are legitimately obscure now.)
> Is there a compiler that really does this?
Here's a popular one with hobbyists in 2022. The definition of uint8_t in the Arduino system header files is not "unsigned char". I have seen this definition used elsewhere too:
https://forum.arduino.cc/t/definition-of-uint8_t/177947 https://forum.arduino.cc/t/mismatching-integer-type-definiti...Except that __attribute__((__mode__(__QI__))) makes that effectively equivalent to "unsigned char".
From https://groups.google.com/g/comp.lang.c/c/sE6I4sgGyPs
So, that means that there are currently zero existing compilers that treat uint8_t differently from unsigned char.
Pretty sure I remember a GCC bug that amounted to uint8_t behaving differently to unsigned char wrt aliasing. It's the sort of thing I'd expect clang to do too.