> Trying to pack the structure makes no sense since this is a speed
> hack over reading the source magic file and any machine that needs
> proper alignment will need lots of shift and mask code.

Agreed.

> Padding it out to worst case bounadries will break binary
> compatibility with architectures that don't bother with alignment.

There is no such thing as a "worst-case boundary" from a C point of
view; the compiler is free to insert 43 pad bytes between two adjacent
"char" elements if it happens to feel like it.  I'm not even certain
there's a requirement that it lay out the same structure the same way
on two different compilation runs, though there may well be, since as a
practical matter not doing so would break separate compliation rather
badly.

Of course, since NetBSD uses gcc, we can to a certain extent depend on
how gcc lays out structs.  But we have to be careful to make sure the
host build tools lay out the struct the way the gcc-built reading code
expects - or else, as has been mentioned, defer the binary file build
until later, when it can be done by fully native code.

And as you point out, there's binary compatability with the past to
worry about.

/~\ 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