cvs commit: src/include ar.h

[Tom Rhodes]

On Mon, 13 Nov 2006 10:18:08 -0700 (MST)
"M. Warner Losh" <imp at bsdimp.com> wrote:

> In message: <20061113173927.Q75708 at delplex.bde.org>
>             Bruce Evans <bde at zeta.org.au> writes:
> : In <ar.h>, all struct members are char arrays so there will be no
> : padding in practice.
> 
> Actually, that isn't the case at all.  There are many systems that
> pad/align structs to 4 byte boundaries regardless.  NetBSD has many of
> these places tagged with __packed since they run on more architectures
> than they can hand tweek for.
> 
> : Most system headers depend on the padding being
> : the same for all compilers, even when the struct member types are very
> : varied.  Many system headers use explicit manual padding to try to
> : give a fixed layout.  This works in practice, and the not-unused file
> : system ffs and the not-unused networking component netinet depend on
> : it working.  Most file systems probably depend on it working across
> : OS's for very varied struct types.  One exception is msdosfs -- since
> : msdosfs's disk data structures are poorly laid out even for an 8-bit
> : system, they are almost perfectly misaligned even for a 16-bit system,
> : so manual packing is not practical, and msdosfs declares most of the
> : structures as byte arrays in much the same way as <ar.h>.  It doesn't
> : go as far as using a single array of bytes with fake struct members
> : defined via offsets into the array, as might be required to be portable
> : in theory.
> 
> "almost" "in theory".  These are nice words, but don't match reality.

I think this is a fortune candidate.  You are so quotesfiled
Mr. Warner.  ;)

> On the arm, the __packed is absolutely required to not only compile,
> but produce correct code.
> 

This is a hardware thing correct?  Admittedly so, I have no clue
about ARM.

-- 
Tom Rhodes