Bit field and storage block
I have a doubt about my compiler using a 32 bit compiler (GCC MinGW) on a 64 bit machine. When I use this structure:
struct S
{
unsigned int a : 2;
unsigned int b : 3;
unsigned int c : 4;
_Bool d : 1;
} s;
sizeof s
returns 8, so my compiler uses my machine word to make 8 bits (64 bits) for bit by bit fields. Why if the compiler is 32 bit? Actually sizeof(int)
give me 4.
Moreover, if I declare my structure as:
struct S
{
char a;
char b;
char c;
_Bool d;;
} s;
sizeof s
give me 4, so it's better to pack the structure in a way that saves more space. It is often said that using a bitfield with structure can save space ... but I think this is not always the case ... Am I missing information?
source to share
Battlefields are mostly defined or even undefined.
I'm guessing that going from unsigned int
to _Bool
caused your compiler to start a completely new bitfield.
Either way, you are correct with final permission:
If you want something reliable and / or portable, package them yourself.
Here are all relevant parts from the C99 + amendments (n1570).
6.7.2.1 Structure and union specifications
[...]
5-bit field must be of a type which is a qualified or unqualified version of_Bool
,signed int
,unsigned int
or other specific type of implementation. It is implementation-defined whether atomic types are allowed.
[...]
10 10 A bit field is interpreted as having a signed or unsigned integer consisting of the specified number of bits (.125). If a value of 0 or 1 is stored in a bit field with a non-zero type width_Bool
, the value of the bit field must be compared with the stored value; a_Bool
bitfield has the semantics of a_Bool
.
11 An implementation MAY allocate any address storage unit large enough to store the bit field. If there is enough space left, the bit-field that immediately follows another bit-field in the structure should be packed into adjacent bits of the same block. If there is not enough space, then whether the bit-field that does not fit will fit into the next block or overlap adjacent ones is implementation-defined. The order in which the bit-fields are allocated within one (from high order to low order or low order) is implementation-defined. The storage address block alignment is undefined.
12 Bit-field declaration with no declarator, but only colon and width, indicates an unnamed bit-field .126). As a special case, a 0-width bit-field structure element indicates that no additional bit-field should be packed into the block in which the previous bit-field was placed, if any.
[...]
15 Within the structure object, members that are not bit fields and the blocks in which the bit fields are located have addresses that are incremented in the order in which they are declared. A pointer to a structure object, appropriately transformed, points to its original member (or if that member is a bitfield, then the block it is in) and vice versa. A structural object can have an unnamed addition, but not at its beginning.
[...]
source to share