In some email I received from Perry E. Metzger, sie wrote:
> 
> Recent, er, issues involving ip.h have lead me to ask the following
> question: why do we have a struct ip?
> 
> In all our drivers and other code, we very strongly DISCOURAGE the
> idea of using structures hacked up with bitfields and alignment
> options as in-core representations of stuff we shove out to devices or
> the wire. This is the rule in almost all our code. We would kill
> anyone for writing a SCSI driver that used structures and
> bitfields. It is all way to dangerous because of compiler and MD
> issues.
> 
> However, in our IP stack, we use a structure -- and even a structure
> with bitfields and the need to do worry about packing -- as a
> representation of the on the wire format.
> 
> I know this is tradition, but it strikes me as dangerous, and we've
> seen the results of it several times. We've even been forced to solve
> several recent bugs with manifestly GCC dependent goo in order to deal
> with ugly problems. Should we be moving to a different paradigm more
> like that we use everywhere else?

FYI, the TCP header is built the same way in tcp.h.

I think there would be more pain experienced as a result of changing
either "struct ip" or "struct tcphdr", or even just using different
structs within the kernel, than there would be benefit gained.

If such a change were to be made, then it should also be made up of
char's everywhere and no short/long members so it can be used with
unaligned pointers.

Consider this - there are applications from here to the sun which
use those header files, in /usr/include/netinet - those structures
are almost a de facto standard by themselves.

I don't like the last part of your justification, however - that is
we should write code which doesn't get screwed over by GCC bugs.
That's just not the way it should be.  We shouldn't be making excuses
for lossage that isn't our fault.

Darren