Date: Mon, 15 Jul 2002 04:24:33 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Luigi Rizzo <luigi@FreeBSD.org> Cc: Mike Barcroft <mike@FreeBSD.org>, current@FreeBSD.org Subject: Re: different packing of structs in kernel vs. userland ? Message-ID: <3D32B0F1.27EA45EE@mindspring.com> References: <20020714011810.A72236@iguana.icir.org> <20020714203642.GD314@crow.dom2ip.de> <20020714230821.C64412@espresso.q9media.com> <20020715105158.GA314@crow.dom2ip.de> <20020715040008.A85276@iguana.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote:
> sorry but all this just does not make sense to me.
>
> sizeof(foo) should give the same result irrespective of
> where you use it.
>
> Perhaps the best thing would be to put a
>
> printf("struct ip_fw has size %d\n", sizeof(struct ip_fw));
>
> both in ipfw2.c and somewhere in ip_fw2.c and see if there is
> a mismatch between the two numbers.
I have to assume that what didn't make sense was that his patch
worked? 8-).
He's making the valid point that for:
struct foo *fee;
It's possible that:
sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0]))
because of end-padding, which is not accounted for in arrays,
and that inter-structure padding depends on ordering of elements
(for a good example of this, see the struct direct name element
reference macro, which is also padding independent).
Basically, end-padding happens because arrays of structures need to
have their first element properly aligned, so there is a pad added
after each element to ensure that the following element starts on
an alignment boundary.
I still say that on 486 and higher, the "disallow unaligned access"
bit in the processor control register should be enabled, so your
kernel will panic if you try this. 8-).
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D32B0F1.27EA45EE>