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:
...
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)++; /* 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 the following noncompliant code, 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?
...
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 | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
EXP11-C | medium | probable | medium | P8 | L2 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Compass/ROSE |
|
| Can detect violations of this recommendation. Specifically, it reports violations if
| ||||||
| 94 S | Fully implemented. | |||||||
PRQA QA-C |
| 0310 | Partially implemented |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this recommendation on the CERT website.
Related Guidelines
CERT C++ Secure Coding Standard | AccessingEXP11-CPP. Do not apply operators expecting one type to data of an incompatible type | ISO/IEC TR 17961 (Draft) | an | object through a pointer to anincompatible type | [ptrcomp]|
---|---|---|---|---|---|
ISO/IEC TR 24772 | "STR Bit representations" | ||||
MISRA | Rule 3.5 |
Bibliography
[ISO/IEC 9899:2011] | Section 6.7.2, "Type Specifiers" |
[Plum 1985] | Rule 6-5 |
...