The internal representations of bit-field structures have several properties (such as internal padding) that are implementation-defined. Additionally, bit-field structures have several implementation-defined constraints:
- The alignment of bit-fields in the storage unit . For (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 a storage unit boundary.
Consequently, it is impossible to write portable safe code that makes assumptions regarding the layout of bit-field structure members.
Noncompliant Code Example (Bit-Field Alignment)
Bit-fields can be used to allow flags or other integer values with small ranges to be packed together to save storage space. Bit-fields can improve the storage efficiency of structures. Compilers typically allocate consecutive bit-field structure members into the same int
-sized storage, as long as they fit completely into that storage unit. However, the order of allocation within a storage unit is implementation-defined. Some implementations are right-to-left: the first member occupies the low-order position of the storage unit. Others are left-to-right: the first member occupies the high-order position of the storage unit. Calculations that depend on the order of bits within a storage unit may produce different results on different implementations.
...
Code Block | ||||
---|---|---|---|---|
| ||||
struct bf { unsigned int m1 : 8; unsigned int m2 : 8; unsigned int m3 : 8; unsigned int m4 : 8; }; /* 32 bits total */ void function() { struct bf data; unsigned char *ptr; data.m1 = 0; data.m2 = 0; data.m3 = 0; data.m4 = 0; ptr = (unsigned char *)&data; (*ptr)++; /* canCan increment data.m1 or data.m4 */ } |
...
This compliant solution is explicit in which fields it modifies.:
Code Block | ||||
---|---|---|---|---|
| ||||
struct bf { unsigned int m1 : 8; unsigned int m2 : 8; unsigned int m3 : 8; unsigned int m4 : 8; }; /* 32 bits total */ void function() { struct bf data; data.m1 = 0; data.m2 = 0; data.m3 = 0; data.m4 = 0; data.m1++; } |
Noncompliant Code Example (Bit-Field Overlap)
In the following this noncompliant code example, assuming 8 bits to a byte, if bit-fields of 6 and 4 bits are declared, is each bit-field contained within a byte, or are the bit-fields split across multiple bytes?
Code Block | ||||
---|---|---|---|---|
| ||||
struct bf { unsigned int m1 : 6; unsigned int m2 : 4; }; void function() { unsigned char *ptr; struct bf data; data.m1 = 0; data.m2 = 0; ptr = (unsigned char *)&data; ptr++; *ptr += 1; /* whatWhat does this increment? */ } |
If each bit-field lives within its own byte, then m2
(or m1
, depending on alignment) is incremented by 1. If the bit-fields are indeed packed across 8-bit bytes, then m2
might be incremented by 4.
...
This compliant solution is explicit in which fields it modifies.:
Code Block | ||||
---|---|---|---|---|
| ||||
struct bf { unsigned int m1 : 6; unsigned int m2 : 4; }; void function() { struct bf data; data.m1 = 0; data.m2 = 0; data.m2 += 1; } |
...
Making invalid assumptions about the type of type-cast data, especially bit-fields, can result in unexpected data values.
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
EXP11-C |
Medium |
Probable |
Medium | P8 | L2 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Astrée |
| Supported: Astrée reports runtime errors resulting from invalid assumptions. | |||||||
Compass/ROSE |
Can detect violations of this recommendation. Specifically, it reports violations if |
|
|
Helix QAC |
|
|
|
94 S
95 S
Fully implemented.
C0310, C0751 | ||
LDRA tool suite |
|
|
|
554 S |
Fully implemented |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this recommendation on the CERT website.
Related Guidelines
SEI CERT C++ |
Coding Standard | VOID EXP11-CPP. Do not apply operators expecting one type to data of an incompatible type |
ISO/IEC TR 24772:2013 | Bit |
Representations [STR] |
MISRA |
C:2012 |
Bibliography
Directive 1.1 (required) |
Bibliography
[Plum 1985] | Rule 6-5: In portable code, do not depend upon the allocation order of bit-fields within a word |
...
...