Page History

C has very weak typing. It lets you type-cast memory to different types, allowing you to apply operations of one type to apply to data of a different type. However, the internal representation of most types are system-dependent. Consequently, applying operations that expect a certain type of data will yield unexpected results when applied to data of the wrong type. Furthermore, applying operations on improper types will yield non-portable code, due to the platform-dependent representation of the data.

Non-Compliant Code Example (Ints vs. Floats)

The following code demonstrates the perils of operating on data of improper types. It tries to increment an int typecast as a float, and a float typecast as an int, and displays the results.

#include <assert.h>
#include <stdio.h>

int main() {
  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

Compliant Solution (Ints vs. Floats)

Here the pointers are assigned to the variables of the proper data types.

#include <stdio.h>

int main() {
  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.

Bit-Fields

The internal representation of bit-field structs The internal representation of Structs have several properties that are implementation-defined. For instance, they may contain internal padding. Bit-field structures have several additional 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 difficult impossible to write portable safe code that makes assumptions regarding the layout of structure members, and it is impossible to write portable code that makes assumptions about the layout of bit-field structures.This rule is similar to ARR37-C. Do not add or subtract an integer to a pointer to a non-array objectstructure 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.

...

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 code also violates ARR37-C. Do not add or subtract an integer to a pointer to a non-array object

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 this non-compliant example, 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?

...

This code also violates ARR37-C. Do not add or subtract an integer to a pointer to a non-array object

Compliant Solution (Bit-Field Overlap)

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

Risk Assessment

Making invalid assumptions about the type of a typecast data, especially bit-field or its layout 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|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

...