------- 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 <[email protected]> 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 -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
