EXP11-A. Do not apply operators expecting one type to data of an incompatible type

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 non-portable code and produce unexpected results.

Non-Compliant Code Example (Integers vs. Floats)

The following non-compliant 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.

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:

int is 0, float is 0.000000
int is 1065353216, float is 0.000000

Compliant Solution (Integers vs. Floats)

In this compliant solution, the pointers are assigned to variables of compatible data types.

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:

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 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.

Non-Compliant 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.

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 */
}

Compliant Solution (Bit-Field Alignment)

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++;
}

Non-Compliant Code Example (Bit-Field Overlap)

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.

Compliant Solution (Bit-Field Overlap)

This compliant solution is 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;
}

Risk Assessment

Making invalid assumptions about the type of type-cast data, especially bit-fields, can result in unexpected data values.

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"
[[ISO/IEC PDTR 24772]] "STR Bit Representations"
[[MISRA 04]] Rule 3.5
[[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