...
It is implementation-defined whether the specifier int designates the same type as signed int or the same type as unsigned int for bit-fields. C99 integer promotions also requires that "If an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int."
...
The first interpretation is that when this value bits.a is used as an rvalue (e.g., lvalue = rvalue), the type is "unsigned int" as declared. An unsigned int cannot be represented as an int, so integer promotions require that this be an unsigned int, and hence consequently "unsigned".
The second interpretation is that (bits.a is an 8-bit integer. As a result, this eight bit value can be represented as an int, so integer promotions require that it be converted to int, and hence consequently "signed".
The type of the bit-field when used in an expression also has implications for long and long long types. Compilers that follow the second interpretation of the standard and determine the size from the width of the bit-field will promote values of these types to int. For example, gcc interprets the following as an eight bit value and promote it to int:
| Code Block |
|---|
struct {
unsigned long long a:8;
} ull = {255};
|
The following attributes of bit-fields are also implementation defined:
- The alignment of bit-fields in the storage unit. For example, the bit-fields may be allocated from the high end or the low end of the storage unit.
- Whether or not bit-fields can overlap an storage unit boundary. For example, assuming eight bits to a byte, if bit-fields of six and four bits are declared, is each bitfield contained within a byte or are they be split across multiple bytes?
...
Risk Assessment
Making invalid assumptions about the type of a bit-field or its layout can result in unexpected program flow.
...