> >	- yes, enums can be "better" than #define's for magic numbers
> 
> True.
> 
> >	- neither structures nor bitfields should ever be contemplated
> >          when trying to map meaning onto external data, especially in
> >          any program that might ever even possibly be run more than
> >          once, and especially if it might ever be re-compiled!  ;-)
> 
> Yes.

Well, that's the end of struct ip.

The reality is if you do not use structures and bitfields then you
end up with code that is unreadable and untype checked.

The reality is that masking, shifting, or otherwise manipulating
an int that interacts with external data is also non-portable.
Iff you are willing to risk that your ints are wide enough and
iff you don't make presumptions about ints being short enough,
THEN you can portably build up int's from chars, ONE AT A TIME.

The structure of information must be defined somewhere. Without
bitfields / structs you are defining this structure in a manner
that spreads it ALL OVER the code that uses it and not in any
central place. Consequently the structure is redunently defined.
I shouldn't need to explain to this audience the evils of redundant
code.

Compiler forced structure alignments are a painful. However a
correctly designed structure need not suffer from this. If alignment
is important to you do not use int, short, but use u_32, u_16 etc.
All modern compilers have the equivalent of __attribute__(packed|aligned)
etc. Use them.

Compilers change less often than programmers do. Further it is simple to
place regression tests in the code to make sure your compiler is behaving
as expected. The same can not be said for meat.

Julian.