The following attributes of bit-fields are implementation-defined:

• 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 code that makes assumptions about the layout of bit-field structures.

Non-Compliant Code Example (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 m1 : 8;
  unsigned m2 : 8;
  unsigned m3 : 8;
  unsigned 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 m1 : 8;
  unsigned m2 : 8;
  unsigned m3 : 8;
  unsigned 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 (Alignment)

This compliant solution is explicit in which fields it modifies.

struct  bf {
  unsigned m1 : 8;
  unsigned m2 : 8;
  unsigned m3 : 8;
  unsigned 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 (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?

struct  bf {
  unsigned m1 : 6;
  unsigned 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? */
}

In the above example, 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 (Overlap)

This compliant solution is also explicit in which fields it modifies.

struct  bf {
  unsigned m1 : 6;
  unsigned 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 bit-field or its layout 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

INT10-A. Do not assume a positive remainder when using the % operator      04. Integers (INT)       INT12-A. Do not make assumptions about the type of a plain int bit-field when used in an expression