> 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.
Comments
> 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.