Re: alignment

[Guy Harris <gharris () sonic net>]

On Sun, Nov 10, 2002 at 01:56:23AM +0900, Jun-ichiro itojun Hagino wrote:
>       i mean, if there's any structure decl which depends on automatic
>       padding now, the struct definition will be interpreted differently
>       on 64bit and 32bit arch (= doesn't work correctly).

*Might* be interpreted differently.

I would expect compilers on at least some 64-bit architectures to lay
out

        struct foo {
                u_int32_t       a;
                u_int8_t        b;
                u_int32_t       c;
        };

the same as

        struct foo_padded {
                u_int32_t       a;
                u_int8_t        b;
                u_int8_t        pad[3];
                u_int32_t       c;
        };

as there's nothing in the structure requiring more than a 32-bit
alignment.  (In fact, I'd be surprised if compilers on *any* 64-bit
architecture put more than 3 bytes of padding before "c".)

Now, a compiler on a 64-bit architecture might add an *additional* four
bytes of padding to pad "struct foo" - or "struct foo_padded" - to a
multiple of 8 bytes, but that can even happen on 32-bit architectures;
at least some versions of GCC on ARM apparently pad all structures to a
multiple of 4 bytes, which is why "ether.h" defines ETHER_HDRLEN as 14
and why "print-ether.c" uses ETHER_HDRLEN rather than "sizeof (struct
ether_header)".
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe