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.) _______________________________________________ Ethereal-dev mailing list [EMAIL PROTECTED] http://www.ethereal.com/mailman/listinfo/ethereal-dev
