Bit-fields can be used to allow flags or other integer values with small ranges to be packed together to save storage space.
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. According to the C Standard [ISO/IEC 9899:2011], C integer promotions also require that "if an int
can represent all values of the original type (as restricted by the width, for a bit-field), the value is converted to an int
; otherwise, it is converted to an unsigned int
."
This issue is similar to the signedness of plain char
, discussed in INT07-C. 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 behavior is the same 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 previously when the specified width is at least as narrow as CHAR_BIT*sizeof(int)
, but wider bit-fields are not portable.
Noncompliant Code Example
This noncompliant 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 { int a: 8; } bits = {255}; int main(void) { printf("bits.a = %d.\n", bits.a); return 0; }
Compliant Solution
This compliant solution uses an unsigned int
bit-field and does not depend on implementation-defined behavior:
struct { unsigned int a: 8; } bits = {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.
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
INT12-C | Low | Unlikely | Medium | P2 | L3 |
Automated Detection
Tool | Version | Checker | Description |
---|---|---|---|
Astrée | 24.04 | bitfield-type | Fully checked |
Axivion Bauhaus Suite | 7.2.0 | CertC-INT12 | |
CodeSonar | 8.1p0 | LANG.TYPE.BFSIGN | Bit-field signedness not explicit |
Compass/ROSE | |||
1.2 | CC2.INT12 | Fully implemented | |
Helix QAC | 2024.3 | C0634, C0635 | |
Klocwork | 2024.3 | MISRA.BITFIELD.TYPE | |
LDRA tool suite | 9.7.1 | 73 S | Fully implemented |
Parasoft C/C++test | 2023.1 | CERT_C-INT12-a | Bit fields shall only be defined to be of type unsigned int or signed int |
PC-lint Plus | 1.4 | 846 | Fully supported |
Polyspace Bug Finder | R2024a | Checks for bit-field declared without appropriate type (rec. fully covered) | |
RuleChecker | 24.04 | bitfield-type | Fully checked |
SonarQube C/C++ Plugin | 3.11 | S814 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
SEI CERT C++ Coding Standard | VOID INT12-CPP. Do not make assumptions about the type of a plain int bit-field when used in an expression |
ISO/IEC TR 24772:2013 | Bit Representations [STR] |
MISRA C:2012 | Rule 10.1 (required) |
Bibliography
[ISO/IEC 9899:2011] | Subclause 6.3.1.1, "Boolean, Characters, and Integers" |
3 Comments
Chris Tapp
Is this the correct interpretation of the implementation-defined behavior?
I always thought the issue was similar to that associated with char, signed char and unsigned char. i.e. if a bit-field is of type int, then it is implementation defined if it is signed or unsigned. If the signedness is specified, the behavior (when used in an expression) is then appropriate for the type of the definition. e.g.
In the above, a.m has implementation defined signedness, ua.m is unsigned and sa.m is signed.
This is the interpretation that MISRA uses.
David Keaton
The real issue is almost the same as that for plain
char
. This rule originally contradicted itself by quoting the integer promotions in the second paragraph, and then later saying that it was implementation-defined whether an 8-bitunsigned int
bit-field was promoted toint
orunsigned int
. The integer promotions are the correct interpretation. This is now fixed.Douglas A. Gwyn
If it's signed int, the 255 initializer is invalid and should generate a diagnostic.
I don't have a good replacement, since my personal rule is "don't use bit fields, ever".