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 a storage unit boundary.
Consequently, it is impossible to write portable code that makes assumptions about the layout of bit-fields field 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 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-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.
...
Conversely, left-to-right implementations will allocate struct bf
as one storage unit with the 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 m1 : 8;
unsigned m2 : 8;
unsigned m3 : 8;
unsigned m4 : 8;
}; /* 32 bits total */
void function() {
struct bf data;
data.m1 = 0;
data.m2 = 0;
data.m3 = 0;
data.m4 = 0;
char* ptr = (char*) &data;
(*ptr)++; /* could increment data.m1 or data.m4 */
}
|
Compliant Solution (alignment)
This code is explicit about the fields it modifies.
Code Block | ||
---|---|---|
| ||
struct bf {
unsigned m1 : 8;
unsigned m2 : 8;
unsigned m3 : 8;
unsigned m4 : 8;
}; /* 32 bits total */
void function() {
struct bf data;
data.m1 = 0;
data.m2 = 0;
data.m3 = 0;
data.m4 = 0;
data.m1++;
}
|
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?
Code Block | ||
---|---|---|
| ||
struct bf {
unsigned m1 : 6;
unsigned m2 : 4;
};
void function() {
struct bf data;
data.m1 = 0;
data.m2 = 0;
char* ptr = (char*) &data;
ptr++;
*ptr += 1; /* what does this increment? */
}
|
In the above example, if each bitfield lives within its own byte, then m2 (or m1, depending on alignment) is incremented by 1. If the bitfields are indeed packed across 8-bit bytes, then m2 might be incremented by 4.
Compliant Solution (overlap)
Code Block | ||
---|---|---|
| ||
struct bf {
unsigned m1 : 6;
unsigned m2 : 4;
};
void function() {
struct bf data;
data.m1 = 0;
data.m2 = 0;
data.m2 += 1;
}
|
Risk Assessment
Making invalid assumptions about the type of a bit-field or its layout can result in unexpected program flowdata values.
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
INT11-A | 1 (low) | 1 (unlikely) | 2 (medium) | P2 | L3 |
...