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.
Consequently, it is impossible to write portable code that makes assumptions about the layout of bit-fields structures.
Non-Compliant Code Example (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 fields can improve storage efficiency. Compilers typically allocate consecutive bit-field structure members to 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-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 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.
struct bf {
unsigned m1 : 8;
unsigned m2 : 8;
unsigned m3 : 8;
unsigned m4 : 8;
}; /* 32 bits total */
Right-to-left implementations will allocate struct bf as one storage unit with the format:
m4 m3 m2 m1
Conversely, left-to-right implementations will allocate struct bf as one storage unit with the format:
m1 m2 m3 m4
Compliant Solution (alignment)
Non-Compliant Code Example (overlap)
In this non-compliant 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?
Compliant Solution (overlap)
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 |
|---|---|---|---|---|---|
INT11-A |
1 (low) |
1 (unlikely) |
2 (medium) |
P2 |
L3 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
[[ISO/IEC 9899-1999]] Section 6.7.2, "Type specifiers"
[[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]] Rule 6-5
INT10-A. Do not make assumptions about the sign of the remainder when using the % operator 04. Integers (INT) INT12-A. Do not make assumptions about the type of a bit-field when used in an expression