Bit field and union size

Question

#include<stdio.h>
main()
{
    union d
    {
        unsigned int a:1;
        unsigned int b:3;
        unsigned :0;
        unsigned int d:1;
        unsigned int e:1;
    };
    union d aa;
    aa.b=9;
    printf("d.aa.a=%d d.aa.b=%d",aa.a, aa.b);
system("pause");
}

In this question, the size of union would be different from the no of bit fields allocated for the union. Can anyone explain the difference.. and what happens to the remaining memory?

More homework? (http://stackoverflow.com/questions/17731253/store-bits-in-an-integer-value-in-c#comment25847570_17731253). Memory access and byte alignment springs to mind. The bus is only a certain size so the spare seats are not used. — Ed Heal, Jul 18 '13 at 20:20
Well, a union is the size of the largest item...also, you can't have a fraction of an `unsigned int`, so the size will be rounded up to a "whole" `unsigned int`. — Drew McGowen, Jul 18 '13 at 20:22
tim.cc: In function ‘int main()’: tim.cc:14:7: warning: large integer implicitly truncated to unsigned type [-Woverflow] tim.cc:15:35: warning: format ‘%d’ expects a matching ‘int’ argument [-Wformat] — tallen, Jul 18 '13 at 20:34

jxh · Answer 1 · 2013-07-19T01:09:35.337

5

Regarding the size of the type that contains bit-fields, the standard says (C11 6.7.2.1 p11):

An implementation may allocate any addressable storage unit large enough to hold a bit-field.

Since this is a union, and all of the members in the union only use no more than 3 bits from an unsigned int, the size of the union would be at least the size if char, plus padding as required by your system (if any). On many systems it will pad out each unit to the size of the type the bit-field is taken against, so in this case I would expect the size of the union to be the same as the size of an unsigned int (although that may have happened due to normal union padding requirements anyway).

The 0 sized bit-field is a red-herring in a union, but it has special meaning in a struct (C11 6.7.2.1 p12):

A bit-field declaration with no declarator, but only a colon and a width, indicates an unnamed bit-field. As a special case, a bit-field structure member with a width of 0 indicates that no further bit-field is to be packed into the unit in which the previous bit-field, if any, was placed.

So, if your union was a struct instead:

struct d
{
    unsigned int a:1;
    unsigned int b:3;
    unsigned :0;
    unsigned int d:1;
    unsigned int e:1;
};

Then the size of this struct would be at least 2 chars (plus any other padding if required). Most of the time, it would actually come out to the size of 2 unsigned ints.

edited Jul 19 '13 at 01:09

answered Jul 18 '13 at 20:46

jxh

69,070
8
110
193

I didn't knew that. Does this special meaning for 0-width bit-fields in case of `struct` have any real use? – Aseem Bansal Jul 18 '13 at 20:58
@AseemBansal: It is apparently short hand for `unsigned : CHAR_BIT*sizeof(unsigned) - BIT_FIELDS_BEFORE_ME`. – jxh Jul 18 '13 at 21:00
The math fits but I was actually asking for any advantage in a real application. – Aseem Bansal Jul 18 '13 at 21:01
1

@AseemBansal: To answer your question more directly, it explicitly creates padding to allow new bits to be added in the future to that particular unit. – jxh Jul 18 '13 at 21:02
I get it now. Like when we are declaring standard headers for images some bits are to be reserved for future versions. Then this can be used to implement that without breaking compatibility with future standards. Thanks. – Aseem Bansal Jul 18 '13 at 21:05
1

The fact that a bit-field is declared with `unsigned int` and has a type of `unsigned int` for evaluation purposes does not imply that it or the union or struct it is in actually have the size of an `unsigned int`. Per C 2011 (n1570) 6.7.2.1 11, “An implementation may allocate any addressable storage unit large enough to hold a bit-field.” The union could be a single byte, and the struct you show could be two bytes. – Eric Postpischil Jul 19 '13 at 00:32
@EricPostpischil: Nice catch! I've updated the answer accordingly. – jxh Jul 19 '13 at 01:10

score 1 · Answer 2 · edited May 23 '17 at 11:59

Computer architecture have certain word-length. While declaring bit-fields can be efficient if used correctly it wouldn't be efficient if the word-length is variable. I think most compilers would pad bits for efficiency reasons. In simple words the rest of the bits will be lost in most cases.

For simplicity suppose word length is 8 and you use bit-fields of 2 and 3 in a union. I use letters to denote individual bits.

a b c d e f g h

The first 3 bits a, b and c will be used in my example and compiler will make sure that rest of bits are not used.

This can explain it in better words.

However, using bit-fields in unions? I am not sure that is a good idea.

Hope my explanation helped. Any queries?

one uses bit fields in unions all the time when coding device drivers and embedded firmware :-) typically it's a register — tallen, Jul 18 '13 at 20:47

tallen · Answer 3 · 2013-07-18T20:54:50.420

0

dough! the size would be padded to 4 bytes (under most implementations)

so "a" would refer to the first (just next to the zeroth bit :-) bit and "b" to the first three bits and "d" and "e" would both refer to the first bit all of the same 32 bit (4byte) word.

edited Jul 18 '13 at 20:54

answered Jul 18 '13 at 20:29

tallen

677
6
17

1

wait a minute, what does "unsigned :0;" mean? – tallen Jul 18 '13 at 20:30
No, under your scenario, the size of the union would be at least 4. – jxh Jul 18 '13 at 20:31
These are bit fields and add up to less than 32 so the size of the union will probably be 4. – Jim Rhodes Jul 18 '13 at 20:36
dough!, now I see it. – tallen Jul 18 '13 at 20:37

Bit field and union size

3 Answers3