INT11-A. Do not make assumptions about the layout of bit-field structures

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. When used in structure members, bit fields can improve storage efficiency. 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 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 the format:

m4   m3   m2   m1

Conversely, left-to-right implementations will allocate struct bf as one storage unit with the 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;
  data.m1 = 0;
  data.m2 = 0;
  data.m3 = 0;
  data.m4 = 0;
  char* ptr = (char*) &data;
  (*ptr)++; /* could increment data.m1 or data.m4 */
}

Compliant Solution (alignment)

This code is explicit about the 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 bitfield contained within a byte or are they be split across multiple bytes?

struct  bf {
  unsigned m1 : 6;
  unsigned m2 : 4;
};


void function() {
  struct bf data;
  data.m1 = 0;
  data.m2 = 0;
  char* ptr = (char*) &data;
  ptr++;
  *ptr += 1; /* what does this increment? */
}

In the above example, if each bitfield lives within its own byte, then m2 (or m1, depending on alignment) is incremented by 1. If the bitfields are indeed packed across 8-bit bytes, then m2 might be incremented by 4.

Compliant Solution (overlap)

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]] Section 6.7.2, "Type specifiers"
[[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]] Rule 6-5

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