Weak typing in C allows type casting memory to different types. Because the internal representation of most types is system dependent, applying operations intended for data of one type to data of a different type will likely yield nonportable code and produce unexpected results.
Noncompliant Code Example (Integers vs. Floating-Point Numbers)
The following noncompliant code demonstrates the perils of operating on data of incompatible types. An attempt is made to increment an integer-type cast to a floating-point type and a floating-point cast to an integer type.
| Code Block | ||||
|---|---|---|---|---|
| ||||
float f = 0.0;
int i = 0;
float *fp;
int *ip;
assert(sizeof(int) == sizeof(float));
ip = (int*) &f;
fp = (float*) &i;
printf("int is %d, float is %f\n", i, f);
(*ip)++;
(*fp)++;
printf("int is %d, float is %f\n", i, f);
|
The expected result is for both values to display as 1; however, on a 64-bit Linux machine, this program produces:
| Code Block |
|---|
int is 0, float is 0.000000
int is 1065353216, float is 0.000000
|
Compliant Solution (Integers vs. Floating-Point Numbers)
In this compliant solution, the pointers are assigned to reference variables of compatible data types.
| Code Block | ||||
|---|---|---|---|---|
| ||||
float f = 0.0;
int i = 0;
float *fp;
int *ip;
ip = &i;
fp = &f;
printf("int is %d, float is %f\n", i, f);
(*ip)++;
(*fp)++;
printf("int is %d, float is %f\n", i, f);
|
On the same platform, this solution produces the expected output of
| Code Block |
|---|
int is 0, float is 0.000000
int is 1, float is 1.000000
|
Bit Fields
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 */
}
|
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 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.
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;
}
|
Risk Assessment
Making invalid assumptions about the type of type-cast data, especially bit-fields, can result in unexpected data values.
Recommendation | Severity | Likelihood | Detectable |
|---|
Repairable | Priority | Level |
|---|---|---|
EXP11-C | Medium |
Probable |
No |
No |
P4 |
L3 |
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 |
|
95
554 S | Fully implemented |
| Polyspace Bug Finder |
|
|
|
| CERT C: Rec. EXP11-C | Checks for bit fields accessed using pointer. |
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 |
Bibliography
...
| 24772:2013 | Bit Representations [STR] |
| MISRA C:2012 | Directive 1.1 (required) |
Bibliography
...
| : In portable code, do not depend upon the allocation order of bit-fields within a word |
...