Re: Full regular expressions

From: Daniel Black <daniel.subs_at_internode.on.net>
Date: Wed, 16 Jun 2010 14:01:38 +1000

On Wednesday 02 June 2010 03:44:40 Murray S. Kucherawy wrote:
> Currently OpenDKIM doesn't expose full regular expressions to users. This
> is done for the sake of simplicity and accessibility to the wider
> population; the idea is that most people understand use of "*" as a
> wildcard from the shell or even going as far back as DOS days, while full
> regular expressions are more flexible but harder to get right.
> Internally, "*" is translated to ".*", "." converts to "\." and things
> like "^" and "$" are judiciously added, and regular expression code is
> applied, but it presents a much simpler interface.
>
> So here's the question: Are we needlessly simplifying the interface? Would
> people prefer to have full access to regular expressions for writing
> things like the SigningTable? Or would this expose people to shooting
> themselves in the foot?
>
> The most general answer, of course, is "offer both, make it selectable" but
> this complicates the code somewhat. We could do that, but I wonder if
> it's really necessary. Or maybe it's fine the way it is.
>
> Just a thought. Feel free to opine. :)
>
> -MSK

If we offer the posix RE engine unmodified under a different map name it
shouldn't impact on code complexity too much.

As for PCRE I see that it offers inbuilt code, conditional branching and \Q \E
constructs to avoids a bit of the \. and \/ constructs. Each of these can be
achieved with lua or POSIX even though it may not be as neat. It could get
marked as a low priority feature request.

http://en.wikipedia.org/wiki/Comparison_of_regular_expression_engines#Language_features

I was also looking at the tre regex syntax since we're linking there
sometimes. The option for right associative manner seems like something that
would speed up matching of domain names. Again if anything a low pri feature
request.

http://laurikari.net/tre/documentation/regex-syntax/

Daniel
Received on Wed Jun 16 2010 - 04:02:53 PST

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wed Jun 16 2010 - 13:50:01 PST