Question:
Using Visual C++ 6.0, I recently attempted to create a structure to implement a data message that my application had to process. The following code segment produced unexpected results (names have been changed to protect the innocent):

struct X{   BOOL field1 : 4;   BOOL field2 : 2;   BOOL field3 : 1;   BOOL field4 : 1;   BOOL field5 : 4;   BOOL field6 : 4;};struct Y{   BOOL field1 : 1;   BOOL field2 : 1;      ...   BOOL field10 : 1;   int  Spare   : 6;};struct message{   X messageField1;   Y messageField2;};

The structures X and Y were each packed into 16 bits, as I had intended. But the message structure took 64 bits, not 32. I included 16 bits of padding before messageField1 and messageField2. Changing BOOL to unsigned char fixed the problem.

Can you explain this, please?

Answer:
Almost everything about bit-fields is compiler- and platform-dependent. In your example, BOOL appears to be the culprit. BOOL is synonymous with “signed int.” As such, it requires 32-bit alignment on Win32. This means that bit structures that contain less than 32 bits may get additional padding bytes to make them fit into a 32-bit word boundary.

When you define a bit field structure that occupies a total of 16 bits or less, always use char or short. Choosing a larger integral type can cause the insertion of extra padding bytes. Furthermore, using a signed type such as BOOL to define a one-bit field is a bad idea, and it likely will cause unexpected results because a signed field always reserves one bit for the sign. If you need a signed bit field, use at least two bits. Otherwise, use an unsigned type explicitly:

struct BITS{ unsigned char f1: 1; // possible values: 0,1 signed char f2: 2 // possible values: -1,0,1};