> In looking at the statistics BPF keeps, I've discovered what I consider
> to be a serious deficiency.

Definitely.

Just for fun, take a look at the comments in libpcap in all the 
routines that implement "pcap_stats()"; there's an amusing diversity in 
what OS kernels return (if anything), and thus in what the statistics 
you actually get from "pcap_stats()" mean.

(That's why I want a new libpcap API that returns a set of tagged 
statistics, so that you only get the statistics that can be obtained 
from the platform in question, and new statistics can be added without 
breaking binary compatibility or adding Yet Another New API.)

> What I'd like to add is a count of the number of times catchpacket() is
> called - bd_ccount (call it 'Z'.)

That's similar to, but not quite the same as, as 2.4 and later Linux's 
"tp_packets" - they both count packets that passed the filter, not 
packets handed *to* the filter, although the Linux one *doesn't* count 
packets that were dropped; if you called that "W", then (with "Z" being 
the number of packets that passed the filter, and "Y" being the number 
of those packets that dropped the filter, as in your message) W+Y=Z.

(I presume the rationale for the BPF "received by filter" statistic was 
that it lets you get a general idea of how much traffic the filter 
managed to throw out, although without bd_ccount you don't get a 
precise idea of how much it managed to throw out.)

> Whether or not tcpdump adds its own line like:
> 99 packets displayed
>
> is up to it,

Actually, it was up to me, and I *did* add a line like that (it says 
"captured", not "displayed", because you might be printing the packets 
or you might be saving them to a file with "-w"),

> but something that's not easily recognised is that these
> numbers, above, can all be different.

...because people got confused by getting "received by filter" values 
that - even with no filter - didn't match the number of packets that 
were in their capture file.