0

In a structure we normally have contiguous bit-fields; that is, one after the other and adjacent to each other — for example:

struct demo
{
  char a;
  char b:1;
  char c:2;
  char d:2;
  int  e;  
} demo1;

The size of demo1 will be 8 bytes:

  • size = a(1 byte) + bit-fields(1 byte) + gap(2 bytes) + e(4 bytes))

Now consider following structure:

struct demo
{
  char a;
  int  b:1;
  char c;
  char d;
  int  e:2;
} demo1;

When I use sizeof(demo1), it gives me 8 bytes — but I want to know how these bit-fields are presented in memory.

If calculated like above structure size should be:

  • size = a(1 byte) + b(4 bytes) + c(1 byte) + d(1 byte) + e(4 bytes)

During programming we don't bother about this thing that how size will be calculated using sizeof and we even don't use bit-fields at two different locations, but sometimes this type of question is asked by interviewers.

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
Paul Sen
  • 526
  • 1
  • 4
  • 20
  • This answer depends on lot of things. If your compiler re-arranges the structure elements, don't get surprised. :-) – Sourav Ghosh Jul 14 '15 at 07:22
  • Does Compilers have the ability to rearrange the elements.? – Paul Sen Jul 14 '15 at 07:23
  • I cannot quote something right now(running for my lunch), but AFAIK, yes. – Sourav Ghosh Jul 14 '15 at 07:24
  • Maybe you can refer to [How is the size of a struct with Bit Fields determined/measured?](http://stackoverflow.com/questions/4129961/how-is-the-size-of-a-struct-with-bit-fields-determined-measured) – Eric Tsui Jul 14 '15 at 08:03
  • 1
    @SouravGhosh: The compiler does not have permission to reorganize a structure. The address of `a` must be before the address of the unit containing `b`, which must be before the address of `c`, which must be before the address of `d`, which must be before the address of the unit containing `e`. – Jonathan Leffler Jul 14 '15 at 14:25
  • It is mildly curious, though perfectly within the compiler's rights, that the structure is padded to a multiple of 4 bytes. If you added characters `f`, `g`, `h` after `e`, the size might well remain unchanged. And there's not an obvious alignment requirement that the three padding bytes preserve. But, as I said (or implied), the compiler is at liberty to do almost anything with bit fields; almost all the behaviour is implementation defined. When answering interview questions about bit fields, it is important to qualify almost everything with 'it is implementation defined'. – Jonathan Leffler Jul 14 '15 at 14:39

1 Answers1

4

Consecutive (non-zero width) bit-fields can be merged into a single memory location, while a bit-field followed by a non-bit-field are distinct memory locations.

 struct demo
 {
      char a;
      int b:1;
      char c;
      char d;
      int  e:2;
 } demo1;

So in this struct, there is 1 non bit-field and 1 bit-field and then 2 non bit-fields and finally a bit-field.

Having a non-bit-field (or a zero-length bit-field) right after a bit-field member, what follows next will be a different/independent memory location/object.

And also:

A compiler does not reorder the elements of a struct, because that would violate the C standard. Section 6.7.2.1 of the C99 standard states:

Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared.

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
ameyCU
  • 16,489
  • 2
  • 26
  • 41