https://bugs.exim.org/show_bug.cgi?id=1694
--- Comment #5 from Philip Hazel <ph10@???> ---
Zoltan is quite right - and even apart from (*SKIP) and its friends, Perl regex
matching is inherently a forwards thing. In effect, it is doing a depth-first
search of a matching tree, backing up on mismatches to try another branch. I
cannot think of how one can search a tree starting from the branches.
The pcregrep program supports a multiline search. It uses the PCRE_FIRSTLINE
option to require that any match must start within the current line, though it
may extend over any number of line boundaries. In PCRE2 we have recently
generalized this feature to allow the caller to specify an offset within which
any match must start. (This feature is not yet in any release, but it's in the
head code.)
Compiling "the reverse" of a given regex would, if you really wanted to try
doing it, need to be very clearly defined. Features like (*SKIP) would probably
not be supportable. The order in which alternatives are tried is important: the
subpattern (A|B|C) tries A first, and only goes on to B if the rest of the
pattern doesn't match. How would this reverse?
Bottom line: I don't think we will be doing anything like this in PCRE. I'm
sure your best approach is keep jumping backwards through the source, but then
matching a forwards regex, using FIRSTLINE or my (.*) trick to control what is
matched. [Actually, that should be (?:.*) or even just .* without parentheses,
and you need to worry a bit more if the pattern is anchored.]
--
You are receiving this mail because:
You are on the CC list for the bug.
