Edit Question - KnowledgeHub

Title Body

In this answer and the attached comments, Pavel Minaev makes the following argument that, in C, the only types to which uint8_t can be typedef'd are char and unsigned char . I'm looking at this draft of the C standard. The presence of uint8_t implies the presence of a corresponding type int8_t (7.18.1p1). int8_t is 8 bits wide and has no padding bits (7.18.1.1p1). Corresponding types have the same width (6.2.5p6), so uint8_t is also 8 bits wide. unsigned char is CHAR_BIT bits wide (5.2.4.2.1p2 and 6.2.6.1p3). CHAR_BIT is at least 8 (5.2.4.2.1p1). CHAR_BIT is at most 8, because either uint8_t is unsigned char , or it's a non- unsigned char , non-bit-field type whose width is a multiple of CHAR_BIT (6.2.6.1p4). Based on this argument, I agree that, if uint8_t exists, then both it and unsigned char have identical representations: 8 value bits and 0 padding bits. That doesn't seem to force them to be the same type (e.g., 6.2.5p14). Is it allowed that uint8_t is typedef'd to an extended unsigned integer type (6.2.5p6) with the same representation as unsigned char ? Certainly it must be typedef'd (7.18.1.1p2), and it cannot be any standard unsigned integer type other than unsigned char (or char if it happens to be unsigned). This hypothetical extended type would not be a character type (6.2.5p15) and thus would not qualify for aliased access to an object of an incompatible type (6.5p7), whic

Tags (comma-separated) Cancel