4 ms·

There are a few variable size types that make sense in an ABI. Like `size_t` and `(u)intptr_t`. > If I'm being really pedantic, don't even use "char". Carefu

There are a few variable size types that make sense in an ABI. Like `size_t` and `(u)intptr_t`. > If I'm being really pedantic, don't even use "char". Careful about that one. I believe `uint8_t` isn't required to be a character type, which has implications for type based aliasing.

bsder 4y ago
> 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?
- JonChesterfield 4y ago
  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.
- 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 ago
    Except 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.

bsder 4y ago

> 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?

JonChesterfield 4y ago
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.
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 ago
  Except 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.