case 1 :
struct s
{
char c1[6]; // 8
double d; // 8
int i1; // 4
char c2[2]; // 4
int i2; // 4
};
case 2:
struct s
{
char c1[6]; // 8
double d; // 8
int i1; // 4
char c2[2]; // 4
int i2; // 4
float f // 4
};
According to the rules of structure padding shouldn't the size of the
above structure be 28 bytes (for a 32 bit compiler , I am using DEV-C+
+) ? But I got 32 as the answer , using sizeof . And when I added
"float f" to the structure , I was getting the same answer , 32 .
Well , if 32 is right instead of 28 in the first case , then after
adding a float , shouldn't it become 36 ? But even in case 2 , its
32 . Is there more to structure padding than simple clubbing together
in groups of 4 ? Somebody please shed some light ?
No, it shouldn't be 28 bytes for a 32-bit compiler. It should be
whatever the compiler implementer decided it should be. For whatever
reasons the implementer decided.
And some of your assumptions are wrong. You seem to think that the
first member of each struct, "char c1[6]", occupies 8 bytes. I
guarantee you that it does not, never did, never will, and cannot in
C. An array of 6 chars occupies exactly 6 bytes, always has, and
always will.
It may very well be that the second member of your structure, "double
d", has an address that is 8 bytes from the start of the structure.
That does not mean that c1 occupies 8 bytes, it occupies 6 bytes. It
means that the compiler has inserted 2 padding bytes after c1.
Likewise the array c2 does not occupy 4 bytes, but exactly 2 bytes. If
your compiler lays out the structure so that there are 4 bytes between
c2 and i2, that means there are 2 padding bytes after c2.
As for why the size of this structure is 32 bytes, with or without the
final float member, that is because this is what the compiler
implementor(s) decided it should be. Or perhaps always to 16 bytes or
8 bytes. 28 bytes is not an exact multiple of any of these. Nor is
36.
Assuming that you are correct about the sizes other than those for the
two character arrays, the widest member in your structure is an 8-byte
double. It is quite possible that the implementation aligns the size
of the structure to the alignment of its widest member. If doubles
are required to be accessed on 8-byte boundaries, or just more
efficiently accessed that way, the compiler might always add padding
at the end of a structure containing one or more doubles so that the
size of the structure is a multiple of 8.
C guarantees several things about structures:
1. The first member of the structure starts at the same address as
the structure itself, that is there is no padding before the first
member.
2. The members of the structure are allocated in the structure in the
order of their declaration in the structure definition, they are never
rearranged.
3. The size of the structure will be greater than or equal to the sum
of the sizes of its members, never less. There is another language
down the hall where this is not always true.
If you want to know why the implementor(s) of a particular compiler
decided on the alignment and padding strategy that they use, either
ask them (on a gcc mailing list) or ask in a group that supports that
particular compiler.
The behavior that you see is correct under the C standard, and nowhere
does the language define why a particular implementation uses padding
in a particular way.
--
Jack Klein
Home:
http://JK-Technology.Com
FAQs for
comp.lang.c
http://c-faq.com/
comp.lang.c++
http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html