Page History

...

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 C integer promotions also requires require 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."

In the following example:

This is a similar issue to the signedness of plain char, discussed in INT07-A. Use only explicitly signed or unsigned char type for numeric values.  A plain int bit-field that is treated as unsigned will promote to int as long as its field width is less than that of int, because int can hold all values of the original type.  This is the same behavior as that of a plain char treated as unsigned.  However, a plain int bit-field treated as unsigned will promote to unsigned int if its field width is the same as that of int.  This difference makes a plain int bit-field even trickier than a plain char.

Bit-field types other than _Bool, int, signed int, and unsigned int are implementation-defined.  They still obey the integer promotions quoted above when the specified width is at least as narrow as CHAR_BIT*sizeof(int), but wider bit-fields are not portable.

Non-Compliant Code Example

This non-compliant code depends on implementation-defined behavior.  It prints either -1 or 255 depending on whether a plain int bit-field is signed or unsigned.

struct {
    unsigned int a: 8;
} bits = {255};


int main(void) {
    printf("unsigned 8-bit field promotes to %sbits.a = %d.\n",
        (bits.a);
 - 256 >return 0) ? "signed" : "unsigned");
}

The type of the expression (bits.a - 256 > 0) is compiler dependent and may be either signed or unsigned depending on the compiler implementor's interpretation of the standard.

The first interpretation is that when bits.a is used as an 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 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 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:

Compliant Solution

This compliant solution uses an unsigned int bit-field, and does not depend on implementation-defined behavior.

struct {
    unsigned longint long a: 8;
} ullbits = {255};

int main(void) {
  printf("bits.a = %d.\n", bits.a);
  return 0;
}

Risk Assessment

Making invalid assumptions about the type of a bit-field or its layout can result in unexpected program flow.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

\[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\] Section 6.7.2, "Type specifiers"

...