int main()
{
int k;
union jatin{
int i :5;
char j :2;
};
union jatin rajpal;
k= sizeof(rajpal);
printf("%d",k);
return 0;
}
so you could get any output from said:
& what would be the output if instead of union in the above example if
i'll use struct? Could anyon can explain me union behavior.
In all the cases, on the compiler I was testing with, I get 4 as
the output -- which is sizeof(int) on that particular machine.
I also get a warning that char is a non-standard type for a bitfield.
The C99 standard permits bitfield types other than int and unsigned int,
as system extensions, but does not define their behaviour.
In the union case, the compiler is allocating enough space
for a full int. There is no requirement that the compiler allocate
the smallest possible space that would hold the defined bitfield sizes.
The way the relevant clauses are written, a compiler would be
conformant if it always used exactly the same size for any storage
unit that contained a bitfield.
The non-standard char bitfield does not take any more space than
an int bitfield on the particular compiler I am using, so there
there was no need to allocate anything bigger than an int for the
overall storage. But since char bitfields are non-standard, the
standard would have no complaint if a compiler decided that
it needed to allocate 742 bytes for every unit that contained
a char bitfield -- non-standard behaviour can be as unusual as
the compiler writer wants.
In the struct case, you again run into the problme that char
bitfields are non-standard, so you again could get out pretty
much any answer. If the compiler choose to treat them like int
bitfields, then you again encounter the behaviour that a
compiler is allowed to allocate a complete word to hold an
aggregate of bitfields that together fit within the limits of
a word. I am deliberately using "word" non-specifically here
rather than "int", as the compiler is not restricted to
multiples of "int". A compiler is allowed to pack down to
the smallest integral type if it wants, and it is allowed to
use a complete integral type if it wants.
Basically, if you are looking for some kind of promises in
the standards that bitfields will only be a certain size and no
bigger, or that the aggregate size will be as small as possible,
then you will not find those promises.
The only promise is that if you are using int or signed int bitfields,
and the next bitfield would fit within the same allocation unit was was
already started, then it will be put in the same allocation unit. But
if the next bitfield would not fit in the same allocation unit, then it
is up to the compiler as to whether it spans the bitfield, part in each
of the two storage units, or if it instead leaves off filling the first
storage unit and starts a new storage unit for the second bitfield.
If you are expecting portability in the fine details of how
bitfields are handled, then you should stop expecting that. There isn't
even any promise about whether bitfields start filling from
the "beginning" of the storage allocation, or start filling from
the "end" of the storage allocation. In your example, i could
end up stored before or after j in the storage unit, and the
next compiler release on the same system could switch it to
the other way. bitfields are NOT any kind of portable bit-level
storage specification.
