3 ms·

With my assumption, it will be defined as an unsigned char, as it should be.

by xcgvgh 11y ago

to3m 11y ago
But it doesn't have to be - the 8-bit integer types could map to 8-bit implementation-defined integer types instead. Such types would not necessarily to have the same aliasing behaviour as their equivalently sized and equivalently signed character types.
- xcgvgh 11y ago
  Typedef doesn't create a new type, it merely creates a new name for a type. I don't know what you mean by implementation defined integer type. If the implementation is conforming, then any integer type that isn't a basic C integer type, is really just a typedef for one of the basic C integer types ( char, short int, int, long, ... ). In C, with CHAR_BIT defined as 8, unsigned char is the only type that satisfies the requirements of uint8_t. ( It is also possible that it is defined as char, if implementation defines char to have the same range, representation, and behavior as unsigned char. In this case, char effectively becomes unsigned char, but is still a distinct type. The types are compatible (can alias).) Now why is unsigned char the only possibility. Type uint8_t is defined to have two'2 complement, have exactly 8 bits, no padding, and be unsigned. So we need an unsigned integer type. The unsigned type that follows unsigned char in rank is unsigned short char. But this type is defined to have ranges at least from 0 to 65535. Since CHAR_BIT is 8, unsigned short int cannot be used, because it has to have more than 8 bits. As there is no type in rank before unsigned char, it remains the only possibility.
  - julian-klode 11y ago
    You could have types __builtin_type_like_char_that_is_not_char and __builtin_type_like_uchar_that_is_not_uchar
    - xcgvgh 11y ago
      There are no such things in the C Standard.
      - to3m 11y ago
        The standard provides for implementation-defined integer types. See my other comment: https://news.ycombinator.com/item?id=10868435 https://news.ycombinator.com/item?id=10868435 See also this suggestion that the gcc people, true to form, considered making uint8_t something other than unsigned char: https://news.ycombinator.com/item?id=10868953 https://news.ycombinator.com/item?id=10868953
        xcgvgh 11y ago
        I apologize. I wasn't aware of extended integer types.
  - noselasd 11y ago
    No. C allows the implementation(A C compiler) to create an internal integer type that is none of the standard integer types and alias that to (u)intX_t , using an implementation defined mechanism other than typedef. Or it could use a typedef .e.g typedef __special_u8 uint8_t; where the particular compiler internally knows about __special_u8 and treats it differently from unsigned char.

With my assumption, it will be defined as an unsigned char, as it should be.

by xcgvgh 11y ago

With my assumption, it will be defined as an unsigned char, as it should be.

to3m 11y ago

But it doesn't have to be - the 8-bit integer types could map to 8-bit implementation-defined integer types instead. Such types would not necessarily to have the same aliasing behaviour as their equivalently sized and equivalently signed character types.

xcgvgh 11y ago
Typedef doesn't create a new type, it merely creates a new name for a type. I don't know what you mean by implementation defined integer type. If the implementation is conforming, then any integer type that isn't a basic C integer type, is really just a typedef for one of the basic C integer types ( char, short int, int, long, ... ). In C, with CHAR_BIT defined as 8, unsigned char is the only type that satisfies the requirements of uint8_t. ( It is also possible that it is defined as char, if implementation defines char to have the same range, representation, and behavior as unsigned char. In this case, char effectively becomes unsigned char, but is still a distinct type. The types are compatible (can alias).) Now why is unsigned char the only possibility. Type uint8_t is defined to have two'2 complement, have exactly 8 bits, no padding, and be unsigned. So we need an unsigned integer type. The unsigned type that follows unsigned char in rank is unsigned short char. But this type is defined to have ranges at least from 0 to 65535. Since CHAR_BIT is 8, unsigned short int cannot be used, because it has to have more than 8 bits. As there is no type in rank before unsigned char, it remains the only possibility.
- julian-klode 11y ago
  You could have types __builtin_type_like_char_that_is_not_char and __builtin_type_like_uchar_that_is_not_uchar
  - xcgvgh 11y ago
    There are no such things in the C Standard.
    - to3m 11y ago
      The standard provides for implementation-defined integer types. See my other comment: https://news.ycombinator.com/item?id=10868435 https://news.ycombinator.com/item?id=10868435 See also this suggestion that the gcc people, true to form, considered making uint8_t something other than unsigned char: https://news.ycombinator.com/item?id=10868953 https://news.ycombinator.com/item?id=10868953
      - xcgvgh 11y ago
        I apologize. I wasn't aware of extended integer types.
- noselasd 11y ago
  No. C allows the implementation(A C compiler) to create an internal integer type that is none of the standard integer types and alias that to (u)intX_t , using an implementation defined mechanism other than typedef. Or it could use a typedef .e.g typedef __special_u8 uint8_t; where the particular compiler internally knows about __special_u8 and treats it differently from unsigned char.