Re: Improving the data supplied by BPF

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> btw, why is the current `struct bpf_hdr' not packed ? this would
>> avoid the SIZEOF_BPF_HDR hack...
> packing a structure should be avoided when we can force optimal
> packing by re-ordering members because it makes the code compiler
> neutral.

Until you meet a compiler with unusual structure member alignment
rules.  (Nothing says, for exmaple, that a struct beginning with
multiple 64-bit values will have no padding between them - as may very
well happen on a machine with 9- or 18-bit bytes.)

I would much prefer to see a decision whether the interface is "however
this struct turns out to be laid out in memory" (in which case the only
reason to care about padding is efficiency of memory use) or "this
sequence of values of defined sizes, packed tightly" (in which case the
resulting definition may be borderline unimplementable on unusual
architectures - and depending on a struct to get it is, to steal a
phrase, unwarranted chumminess with the compiler).

I've sometimes thought about building a bug-finding compiler, one which
goes out of its way to break common-but-not-guaranteed assumptions
(such as the struct-packing one mentioned above, or "nil pointers of
all types are all the same size and all all-0-bits"), to help people
who want to produce more portable code.

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