4 ms·
> 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 ri
by jlokier 4y ago
> 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__)));
https://forum.arduino.cc/t/definition-of-uint8_t/177947 https://forum.arduino.cc/t/definition-of-uint8_t/177947 https://forum.arduino.cc/t/mismatching-integer-type-definitions-stdint-h/1004510 https://forum.arduino.cc/t/mismatching-integer-type-definiti...
- bsder 4y agoExcept that __attribute__((__mode__(__QI__))) makes that effectively equivalent to "unsigned char". From https://groups.google.com/g/comp.lang.c/c/sE6I4sgGyPs https://groups.google.com/g/comp.lang.c/c/sE6I4sgGyPs > 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.