> I am curious to know why <netinet/ip.h> explicitly packs "struct ip"
> in NetBSD (BTW, I'm on NetBSD-1.5.2/alpha).  None of the other UNIX
> systems I have access to* do this, and I would not think it
> necessary.

It appears - to me - to be not for the sake of structure packing but
rather for the sake of declaring it possibly misaligned.  I tried
copying the declaration and removing the attribute, and none of the
field offsets differed, but __alignof__ the type was then 2, not 1.
(Not, of course, conclusive, but indicative.)  Note that struct in_addr
is declared packed too.

> If the structure is being used when it is not properly aligned
> someplace, then __attribute__((__packed__)) should cause the compiler
> to generate fixups, hiding the problem, right?

Yes.  It's a misnomer, because it's got nothing to do with actually
packing the structure - it should be __attribute__((__unaligned__)), or
perhaps __attribute__((__aligned__(1))) - but it does have that effect.

> But would this not also cause the compiler to possibly generate
> fixups where they are not needed as well?

Yes.  In many (most?) uses of struct ip, the compiler can't know
whether the struct is aligned until run-time (because it's overlaid
onto memory obtained from elsewhere, such as an mbuf).

Of course, overlaying structs onto byte-streams is a philosophically
broken way to pack and unpack them.  Presumably it's done for speed and
compatability with traditional coding - and most (all?) of the machines
where it'll break will break in much noisier ways first (for example,
ISTR hearing that some DSPs are 32-bit and can't address sub-word
quantities, and thus don't, and mostly can't, have u_int8_t and
u_int16_t - char, short, and int are all the same).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B