sizeof and allignment on 32bit target

sizeof and allignment on 32bit target

[Eric de Jong]

Hello,

Who can tell me why sizeof(Test.Value) gives 12 bytes? I expected 10 bytes.
Due to allignment in my 32bit target (both intel and arm) two bytes are added
before 'Value4', and sizeof(TestStruct) is 16bytes
Here is my test program:

test.cpp:
--------
#include "stdio.h"

int main()
{

   struct TestStruct
   {
      struct
      {
         unsigned long Value1;
         unsigned long Value2;
         unsigned short Value3;
      } Value;
      unsigned long Value4;
   } Test;

   printf("\r\n" "Sizeof Test: %d", sizeof(Test));
   printf("\r\n" "Sizeof Value: %d", sizeof(Test.Value));
   printf("\r\n" "Expected size of Value: 10");
}
----------

target:
intel P3, gcc 3.2 20020927 (prerelease)
 - the target was build under cygwin: 'gcc test.cpp' and tested: './a.exe'.
   result:
-----------
$ ./a.exe

Sizeof Test: 16
Sizeof Value: 12
Expected size of Value: 10
-----------
On my ARM target (gcc 3.3) I detected the same problem.

Eric

Re: sizeof and allignment on 32bit target

[Jan Zizka]

Hi,

On Fri, Jul 25, 2003 at 10:13:30AM +0200, Eric de Jong wrote:
>    struct TestStruct
>    {
>       struct
>       {
>          unsigned long Value1;
>          unsigned long Value2;
>          unsigned short Value3;
>       } Value;
>       unsigned long Value4;
>    } Test;

if you should get those 10 you have to add packed attribute to the struct
definition:

    struct TestStruct
    {
       struct
       {
          unsigned long Value1;
          unsigned long Value2;
          unsigned short Value3;
       } Value __attribute__ ((packed));
       unsigned long Value4;
    } Test __attribute__ ((packed));

otherwise the alignment will be always 4 bytes for any structure.

-ziza

Re: sizeof and allignment on 32bit target

[Eric de Jong]

Thank you, Jan Zizka, Roman Kellner

I would expect that the allignment has only influence on the address of
variables, not on the total size of a structure. It looks like the compiler
calculates the size of the structure to be a multiple of the largest item in the
structure.
What I want is to allign each variable in the structure to it's own size, but
the total size of the structure to be the actual size. Is this possible?

Eric

----
  struct { unsigned char Value2; unsigned char Value3; unsigned char Value4; }
Value;
  sizeof(Value) = 3;

  struct { unsigned short Value1; unsigned char Value2; unsigned char Value3;
unsigned char Value4; } Value;
  sizeof(Value) = 6; (not 5)

  struct { unsigned long Value1; unsigned char Value2; unsigned char Value3;
unsigned char Value4; } Value;
  sizeof(Value) = 8; (not 7)

Re: sizeof and allignment on 32bit target

[Michael Meissner]

On Fri, Jul 25, 2003 at 11:28:05AM +0200, Eric de Jong wrote:
> Thank you, Jan Zizka, Roman Kellner
> 
> I would expect that the allignment has only influence on the address of
> variables, not on the total size of a structure. It looks like the compiler
> calculates the size of the structure to be a multiple of the largest item in the
> structure.
> What I want is to allign each variable in the structure to it's own size, but
> the total size of the structure to be the actual size. Is this possible?

Without using packed and aligned attributes, this is not possible.  This can be
a severe performance penalty on many architectures and are not supported by
other compilers.

According to the ISO C90 and C99 standards, the alignment of a structure or
union is at least the maximum of the alignments of each of its members.  A
compiler can make structure and unions have even more alignment than the
alignment of the members, for example some ABI's on word based machines will
align any structure to a word boundary, even if all of the fields are chars,
and on the machine I just did an ABI for, the compiler will align any structure
with 2 or more words to double word alignment so the double word memory
instructions can be more often used.  This wording has been in the C
specification ever since I can remember (and I used C on UNIX V6 PDP-11
machines).

The reason for this is to make arrays and p++ work correctly.  If the size were
smaller, p++ would wind up pointing to unalgined memory.

Note, also you are not guaranteed that short/int/long are the same size or
alignment on different machines either.  If you are reading files produced by
another computer, you have to worry about endian issues as well.

-- 
Michael Meissner
email: gnu@the-meissners.org
http://www.the-meissners.org