3 ms·
They ended up making uint8_t a typedef for unsigned char rather than a distinct type (which is permitted but not required by the standard) so the semantics are
by quietbritishjim 3y ago
They ended up making uint8_t a typedef for unsigned char rather than a distinct type (which is permitted but not required by the standard) so the semantics are now clear.
Edit: That's what I remember but I can't find evidence of it. The docs say this is ABI dependent so perhaps the above statement is true on some specific ABI (if I haven't misremembered it entirely). But I can't track down wheere a relevant ABI would be documented.
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Architecture-implementation.html https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Architecture-i...
Edit 2: this header has a typedef of uint8_t to unsigned char, but it's part of glibc rather than gcc
https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/host/i686-linux-glibc2.7-4.6/+/refs/heads/tools_r20/sysroot/usr/include/stdint.h https://android.googlesource.com/platform/prebuilts/gcc/linu...
- kzrdude 3y agoI thought if uint8_t exists, it logically must be the same as unsigned char? You put some of the statements of the standards together and that's their combined consequence.
- quietbritishjim 3y agoNo it doesn't have to be, and it wasn't. That was the whole problem. They were both unsigned integer types with 8 bit widths but they were distinct and, in particular, uint8_t didn't have the aliasing exception that unsigned char does.