| From: Guy Harris
|
| On Thu, Dec 04, 2003 at 08:36:12AM +0100, Biot Olivier wrote:
| > Not really. I decided to have the "matches" operator always
| available to the
| > dfilter grammar and syntax, but to conditionally attach the
| cmp_matches()
| > function to the relevant ftype-X.c files (actually it's
| only implmented for
| > FT_STRING and similar, all defined in ftype-string.c).
|
| So if you don't have PCRE, the "matches" operator exists in
| the syntax,
| but the semantic code presumably says "it's not supported on that type
| of field" even for strings?
Correct.
| > Maybe I can try to conditionally allow the "matches"
| operator. This'll need
| > some #ifdef HAVE_LIBPCRE ... #endif stuff around my changes in
| > epan/dfilter/.
| >
| > Should I also do this in the different ftype-* files and
| ftype-int.h, or is
| > it OK to leave the cmp_matches() entry in the struct?
|
| Hmm.
|
| Perhaps it should be left in unconditionally, but perhaps the
| error, if
| HAVE_LIBPCRE isn't defined, should be "This version of Ethereal was
| built without the Perl Compatible Regular Expression library, and
| therefore doesn't support the "matches" operator" or something such as
| that?
Sounds fine to me, but this implies that I can set the dfliter error message
to some value, which isn't the case today I think. Additionally, I'd like to
precompile and prestudy the RE only once, which is not possible now either.
Please correct me if I am wrong.
Maybe I'd have to add a line saying something like:
Note: as libpcre is not linked into this Ethereal binary,
the dfilter operator "matches" is not available.
Regards,
Olivier