------- 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 #4 from Simon McVittie <smcv@???> 2014-07-21 10:34:03 ---
The GLib regression tests (specifically glib/tests/regex.c), when GLib is
compiled with --with-pcre=system to avoid its embedded copy of PCRE (currently
8.31), appear to exercise a lot of obscure corners of the PCRE API; they also
caught the behaviour change in 8.34 that (?P<1>) is no longer supported, which
also appears to be deliberate, but also something that can break existing
working code.
For this DFA matching (which I will admit I hadn't even heard of before today
:-), GLib can preserve existing behaviour with the patch that I attached to
<
https://bugzilla.gnome.org/show_bug.cgi?id=733325>; but that doesn't help
other PCRE users, which could have previously-working code that now fails.
http://codesearch.debian.net/search?q=pcre_dfa_exec indicates that nginx,
apertium, emboss, mongodb, freemat, nbci-blast+, lua-rexlib, samhain and clisp
also call this function, for what it's worth.
For (?P<1>), am I right in thinking there is no solution other than "don't do
that"?
It would be great if you could offer an opinion on
<
https://bugzilla.gnome.org/show_bug.cgi?id=733325> as to which of the patches
I attached should be applied to GLib, and which would be better changed in
PCRE. I think the caseless-matching one is pretty clearly a GLib bug, but I'm
not so sure about (?P<1>) or DFAs.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
