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
