The following attributes internal representations of bit-fields are also 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 an a storage unit boundary.
Consequently, it is impossible to write portable safe code that makes assumptions about regarding the layout of bit-fields structuresfield 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. When used in structure members, bit Bit-fields can improve the storage efficiency of structures. Compilers typically allocate consecutive bit-field structure members to into the same int
-sized storage, as long as they fit into that completely into that storage unit. However, the order of allocation within a storage unit is implementation dependent-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.
Consider the following structure made up of four 8-bit bit-field members.:
Code Block |
---|
struct bf { unsigned int m1 : 8; unsigned int m2 : 8; unsigned int m3 : 8; unsigned int m4 : 8; }; /* 32 bits total */ |
Right-to-left implementations will allocate struct bf
as one storage unit with the this format:
Code Block |
---|
m4 m3 m2 m1
|
Conversely, left-to-right implementations will allocate struct bf
as one storage unit with the format:
Code Block |
---|
m1 m2 m3 m4
|
Compliant Solution (alignment)
...
bgColor | #ccccff |
---|
Non-Compliant Code Example (overlap)
this format:
Code Block |
---|
m1 m2 m3 m4
|
The following code behaves differently depending on whether the implementation is left-to-right or right-to-left:
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)++; /* Can increment data.m1 or data.m4 */
}
|
Compliant Solution (Bit-Field Alignment)
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 this noncompliant code example, assuming 8 In this non-compliant example, assuming eight bits to a byte, if bit-fields of six and four of 6 and 4 bits are declared, is each bitfield bit-field contained within a byte, or are they be the bit-fields split across multiple bytes?
Code Block | ||
---|---|---|
|
Compliant Solution (overlap)
| ||
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; /* What 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.
Compliant Solution (Bit-Field Overlap)
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;
}
| ||||
Code Block | ||||
bgColor | #ccccff
Risk Assessment
Making invalid assumptions about the type of a type-cast data, especially bit-field or its layout fields, can result in unexpected program flowdata values.
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
---|
INT11-A
1 (low)
1 (unlikely)
2 (medium)
P2
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 |
| C0310, C0751 | |||||||
LDRA tool suite |
| 554 S | Fully implemented |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule recommendation on the CERT website.
References
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 | 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 |
...
\[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\] Section 6.7.2, "Type specifiers"
\[[MISRA 04|AA. C References#MISRA 04]\] Rule 3.5, Rule 6.4, "Bit fields shall only be defined to be of type unsigned int or signed int"
\[[Plum 85|AA. C References#Plum 85]\] Rule 6-5 Wiki Markup