Re:Tell HN: C Experts Panel – Ask us anything about C
by radford-neal on Tuesday April 14, 2020 @03:10PM
(#22870154)
I don't think it's anything to do with uint8_t being optional. It's because a char might have more than 8 bits.
Re:Tell HN: C Experts Panel – Ask us anything about C
by flatfinger on Thursday April 16, 2020 @05:08PM
(#22893577)
A conforming implementation could extend the language with an 8-bit type __nonaliasingbyte which has no special aliasing privileges, and define uint8_t as being synonymous with that type.
On the other hand, the Standard should never have given character types special aliasing rules to begin with. Such rules would have been unnecessary if the Standard had noted that an access to an lvalue which is freshly visibly derived from another is an access to the lvalue from which it is derived. The question of whether a compiler recognizes a particular lvalue as "freshly visibly derived" from another is a Quality of Implementation issue outside the Standard's jurisdiction.
6.2.5p17 The three types char, signed char, and unsigned char are collectively called the character types. The implementation shall define char to have the same range, representation, and behavior as either signed char or unsigned char. 48)
and
5.2.4.2.1 says that width of char, signed char and unsigned char are the same (8).