[Guy Harris <guy@xxxxxxxxxxxx>]

On Mon, Feb 02, 2004 at 01:14:37AM +0100, Joerg Mayer wrote:
> On Sun, Feb 01, 2004 at 02:38:00PM -0800, Guy Harris wrote:
> > 	2) split "pcap_compile()" into a parser that generates an
> > 	   expression tree and code generators that produce programs,
> > 	   have a routine that takes an expression tree and a pcap_t and
> > 	   either generates code and sets a filter or fails if it can't
> > 	   generate code or set the filter, and have multiple code
> > 	   generators for different filter engines.
> 
> I'd really prefer this solution. The fact that today the syntax for the
> (capture) filters is tied to libpcap but shouldn't be can bee seen in
> the location of the capture filter manpage: It's not in the libs manpage
> but in the applications manpage (tcpdump).

I infer that you're suggesting here that Ethereal would have its own
capture filter syntax (which would probably be a small subset of the
display filter syntax - BPF isn't capable of handling the vast majority
of what can be done with display filters, and is unlikely ever to be
capable of it) and translate that into an expression tree to hand to the
back end?

One disadvantage of that solution is, of course, that you'd only be able
to use it with versions of libpcap that support that split of parsing
and code generation.

It *might* be possible to fall back on having Ethereal generate a
libpcap filter string; one problem is that the libpcap language has had
new capabilities added over time, so Ethereal would either have to
assume something such as libpcap 0.4-vintage expressions, or try new
features and fall back on older mechanisms if the new capabilities are
absent.  (In most cases I think it can probably just generate raw field
tests, although there's a bug in pre-0.8.1 libpcaps that caused the code
generator to leak internal "registers" when doing arithmetic on raw
fields, so there are potential problems with that.)