C has very weak typing. It lets you type-cast memory to different types, allowing you to apply operations of one type to data of a different type. However, the internal representation of most types are system-dependent. Applying operations on improper types will likely yield non-portable code and produce unexpected results.
The following non-compliant code demonstrates the perils of operating on data of improper types. It tries to increment an int type cast as a float, and a float type cast as an int, and displays the results.
#include <assert.h>
#include <stdio.h>
int main(void) {
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);
return 0;
}
|
Rather than the int and float both having the value 1, on a 64-bit Linux machine, this program produces:
int is 0, float is 0.000000 int is 1065353216, float is 0.000000 |
In this compliant solution, the pointers are assigned to the variables of the proper data types.
#include <stdio.h>
int main(void) {
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);
return 0;
}
|
This program, on the same platform, produces:
int is 0, float is 0.000000 int is 1, float is 1.000000 |
which is what one would expect.
The internal representation of bit-field structs have several properties that are implementation-defined. For instance, they may contain internal padding. Bit-field structures have several additional implementation-defined constraints:
Consequently, it is impossible to write portable safe code that makes assumptions regarding the layout of bit-field structure members.
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.
Consider the following structure made up of four 8-bit bit-field members.
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 this format:
m4 m3 m2 m1 |
Conversely, left-to-right implementations will allocate struct bf as one storage unit with this format:
m1 m2 m3 m4 |
The following code behaves differently depending on whether the implementation is left-to-right or right-to-left.
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)++; /* could increment data.m1 or data.m4 */
}
|
This compliant solution is explicit in which fields it modifies.
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++;
}
|
In the following non-compliant code, assuming eight bits to a byte, if bit-fields of six and four bits are declared, is each bit-field contained within a byte or are the bit-fields split across multiple bytes?
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.
This code also violates ARR37-C. Do not add or subtract an integer to a pointer to a non-array object.
This compliant solution is also explicit in which fields it modifies.
struct bf {
unsigned int m1 : 6;
unsigned int m2 : 4;
};
void function() {
struct bf data;
data.m1 = 0;
data.m2 = 0;
data.m2 += 1;
}
|
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 |
|---|---|---|---|---|---|
INT11-A |
low |
unlikely |
medium |
P2 |
L3 |
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
\[[ISO/IEC 9899:1999|AA. C References#ISO/IEC 9899-1999]\] Section 6.7.2, "Type specifiers" \[[ISO/IEC PDTR 24772|AA. C References#ISO/IEC PDTR 24772]\] "STR Bit Representations" \[[MISRA 04|AA. C References#MISRA 04]\] Rule 3.5 \[[Plum 85|AA. C References#Plum 85]\] Rule 6-5 |
EXP10-A. Do not depend on the order of evaluation of subexpressions or the order in which side effects take place 03. Expressions (EXP) EXP30-C. Do not depend on order of evaluation between sequence points