Object storage for exact-width integer types

Question

Are implementations allowed to use more than N bits as object storage for intN_t and uintN_t types, provided the values stored in them fit the required range?

For example, consider a CPU which uses 9-bit bytes. An implementation written for this CPU may have something like typedef __uint8_as_9 uint8_t, assuming __uint8_as_9 refers to a compiler keyword indicating a 9-bit unsigned integer which represents an 8-bit unsigned integer. When the compiler generates code for converting an unsigned int to this type, it may (implicitly) truncate the number to 9 bits, then mask out the highest bit. Is this still considered a conforming definition of uint8_t, seeing as the compiler ensures the 9-bit value is in the range 0 to UINT8_MAX?

Quoting the C standard §7.20.1.1/3, with regards to exact-width integer types (emphasis mine):

These types are optional. However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a two’s complement representation, it shall define the corresponding typedef names.

Since the underlying storage for uint8_t actually consists of 9 bits, is this most-significant bit considered a padding bit? Even if it's completely transparent to any (conforming) programs using this implementation?

Answer 1

A compiler for a system with 9-bit bytes (i.e, CHAR_BIT==9 simply will not define uint8_t or int8_t. If it did, that 9th bit would be a padding bit, which would violate the standard's requirement.

The types are optional and are not provided by implementations that are not able to meet all their requirements.

Such an implementation will still provide [u]int_least8_t and [u]int_fast8_t, and a program can check whether the macro UINT8_MAX is defined to determine whether it can use uint8_t.