Page History

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.

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. When used in structure members, bit Bit-fields can improve the storage efficiency of structures. Compilers will typically allocate consecutive bit-field structure members to into the same int-sized dwordstorage, as long as they fit into that completely into that dwordstorage unit. However, the order of allocation within a word is different in different implementations. This is known as the implementation's endianness. Big endian machines store the most significant bit at the lowest address versus little endian implementations, which store the most significant bit at the highest address. Depending of the order bits within a word can lead to different calculations 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 */

/* ... */

Little endian Right-to-left implementations will allocate struct bf as one storage unit with this format:

m4   m3   m2   m1

Conversely, big endian endian left-to-right implementations will allocate struct bf as one storage unit with this format:

m1   m2   m3   m4

Risk Assessment

Making invalid assumptions about the type of a bit-field or its layout can result in unexpected program flow.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

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)++; /* Can 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++;
}

Noncompliant Code Example (Bit-Field Overlap)

In 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?

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.

Automated Detection

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this recommendation on the CERT website.

Related Guidelines

Bibliography

...

Image Added Image Added Image Added Wiki Markup\[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\] Section 6.7.2, "Type specifiers" \[[MISRA 04|AA. C References#MISRA 04]\] Rule 3.5, Rule 6.4, "Bit fields shall only be defined to be of type unsigned int or signed int" \[[Plum 85|AA. C References#Plum 85]\] Rule 6-5