https://bugs.exim.org/show_bug.cgi?id=1694
--- Comment #5 from Philip Hazel <[email protected]> --- 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. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
