cvs commit: src/include ar.h

[Yar Tikhiy]

On Sun, Nov 19, 2006 at 05:47:40AM +1100, Bruce Evans wrote:
> On Sat, 18 Nov 2006, M. Warner Losh wrote:
> 
> >In message: <20061118214618.U15111 at delplex.bde.org>
> >           Bruce Evans <bde at zeta.org.au> writes:
> >: On Fri, 17 Nov 2006, M. Warner Losh wrote:
> >:
> >: > In message: <20061117201432.X11101 at delplex.bde.org>
> >: >            Bruce Evans <bde at zeta.org.au> writes:
> >: > : For that the comment should be something like:
> >: > :
> >: > :  	__packed;	/* Align (sic) to work around bugs on arm 
> >(*). */
> >: > :
> >: > : but I doubt that arm is that broken.
> >: > :
> >: > : (*) See this thread for more details.
> >: >
> >: > But they aren't bugs.
> >:
> >: Er, this thread gived the details of why they are bugs.
> >
> >Wait, is this the ar or the struct ip thing..  Ar is clearly needed,
> >but I was going to test the packedness on struct ip...  I've just had
> >my first son and am operating on too little sleep :-(.
> 
> I was mostly talking about struct ip.  Something is needed for struct
> ar_hdr, since although it has size a multiple of 4 applications expect
> it to have alignment 1 but arm gives it alignment 4.  Something is needed
> for struct ether_header (which sam recently packed), since it wants to
> have size 14 and alignment 2, but arm gives it size 16 and alignment 4.
> Nothing shoulded be need for struct ip, since it wants to have size 20 and
> alignment 4, and arm gives it that.

The C standard provides no clues as to how structures are packed
or aligned.  The only thing it says is that objects have alignment
and it can be the same or not the same for different objects.  That
is, a future C compiler is allowed to put holes in struct ip, and
in any struct it wants, unless we use the unportable __packed hack
-- or abandon the structs in favor of byte-level access to seamless
data such as hardware or network packets.  That's what I meant by
struct ip being historically lucky.

We still want to use __packed and __align, but IMHO we should realize
that we just pay the price of non-portability for using convenient
things such as struct in low-level programming.  Perhaps we're just
getting even with the C standard authors, who sacrificed the ability
to use struct in that way for the sake of the language's own
portability. :-)

-- 
Yar