[pcre-dev] [Bug 1504] DFA matching seems to have regressed, …

Top Page
Delete this message
Author: Simon McVittie
Date:  
To: pcre-dev
Subject: [pcre-dev] [Bug 1504] DFA matching seems to have regressed, causing GLib test failure
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1504




--- Comment #1 from Simon McVittie <smcv@???> 2014-07-21 09:58:25 ---
git bisect says the culprit is r1363, "Refactored auto-possessification code",
which appears to be an API change:

+NOTE: PCRE's "auto-possessification" optimization usually applies to character
+repeats at the end of a pattern (as well as internally). For example, the
+pattern "a\ed+" is compiled as if it were "a\ed++" because there is no point
+even considering the possibility of backtracking into the repeated digits. For
+DFA matching, this means that only one possible match is found. If you really
+do want multiple matches in such cases, either use an ungreedy repeat
+("a\ed+?") or set the PCRE_NO_AUTO_POSSESSIFY option when compiling.

Is it intentional that this broke existing applications?

This does suggest how GLib can avoid this issue: it can set
PCRE_NO_AUTO_POSSESSIFY, if defined, when using DFA.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email