位字段的意外行为

Question

I compiled the code,

#include <stdio.h>

struct s {
    int a : 6;
    _Bool b : 1;
    _Bool c : 1;
    _Bool d : 1;
    _Bool e : 1;
    _Bool f : 1;
    _Bool g : 1;
    int h : 12;
};

void main(void) {
    printf("%d\n", sizeof(struct s));
}

and the output was a bit unexpected.

12

As stated by the C11 draft,

... If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit...

I expected it to fit into 4 bytes since I used a 32-bit compiler. Specifically, I used gcc (tdm-1) 5.1.0. Is it against the standard?

---

EDIT:

Replacing all the _Bool s to an int works as expected... I'm not sure why...

---

EDIT:

In gcc 5.4.0, the code works as expected. The crucial point of this question is why the trailing _Bool s and the int do not fit into the first one . I think I didn't do much assumptions about the implementation (except int is at least 4 bytes, which is acceptable), and I'm talking here about the guaranteed behavior of C by the C standard . Therefore, I cannot agree with some comments below.

Answer 1

These are bit-fields. There is not much in the way of an "expected" output, as these are very poorly specified by the standard. In addition, compilers tend to have poor support for them.

To begin with, the complete section that you quote (6.7.2.1/11) says:

An implementation may allocate any addressable storage unit large enough to hold a bitfield. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified.

All of this means that you pretty much can make no assumptions about how the bits end up in memory. You can't know how the compiler will arrange alignment, you can't know the bit order of the bits, you can't know the signedness, you can't know the endianess.

As for if int and _Bool will merge into the same "storage unit"... well, why would they? They are incompatible types. The C standard does not mention what will happen when you have two adjacent bit fields of incompatible types - it is left open to subjective interpretation. I suspect that there will be various type aliasing concerns.

So it is perfectly fine for the compiler to put all of these in separate "storage units". If you place items of the same type adjacently, I would however expect it to merge them or the quoted part wouldn't make any sense. For example I would expect size 8 from the following:

struct s {
    int a : 6;
    int h : 12;
    _Bool b : 1;
    _Bool c : 1;
    _Bool d : 1;
    _Bool e : 1;
    _Bool f : 1;
    _Bool g : 1;
};

---

Now what you should do if you want deterministically behaving, portable code is to throw bit-fields out the window and use bit-wise operators instead. They are 100% deterministic and portable.

Assuming you actually don't want some mysterious signed number fields, which your original code hints about, then:

#define a UINT32_C(0xFC000000)
#define b (1u << 18)
#define c (1u << 17)
#define d (1u << 16)
#define e (1u << 15)
#define f (1u << 14)
#define g (1u << 13)
#define h UINT32_C(0x00000FFF)

typedef uint32_t special_thing;

Then design setter/getter functions or macros that sets/gets the data from this 32 bit chunk. Written properly, you can even make such code endianess-independent.

Answer 2

My guess is that the compiler is treating the int bit-fields and _Bool bit-fields as different types. So it combines all of the _Bool bit-fields together and the int bit-fields together, but does not combine _Bool and int bit-fields. So the structure would be put together something like this to make 12 bytes:

struct s {
    int a : 6; // no more int bit-fields, so 4 bytes (usual size)

    // 6 bits fits in one byte, but these might have to be aligned 
    // on a 4 byte boundary for efficient access, so 4 bytes in total
    _Bool b : 1; // combine
    _Bool c : 1; // combine
    _Bool d : 1; // combine
    _Bool e : 1; // combine
    _Bool f : 1; // combine
    _Bool g : 1; // combine with above _Bool bit-fields to make 6 bits

    int h : 12; // no more int bit-fields around again, so 4 bytes
};

EDIT: This paragraph from the 2011 C standard could be interpreted to make _Bool bit-fields act different:

6.7.2.1 Structure and union specifiers
A bit-field is interpreted as having a signed or unsigned integer type consisting of the specified number of bits. If the value 0 or 1 is stored into a nonzero-width bit-field of type _Bool, the value of the bit-field shall compare equal to the value stored; a _Bool bit-field has the semantics of a _Bool.

If a _Bool bit-field has the semantics of a _Bool, then perhaps the implementer interpreted that as to say "Act like _Bool b : 1; is equivalent to _Bool b; "

A quick test here seems to confirm this theory.