https://bugs.exim.org/show_bug.cgi?id=2120
Philip Hazel <p...@hermes.cam.ac.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #20 from Philip Hazel <p...@hermes.cam.ac.uk> ---
I thought about this, and checked up on Perl, which turns out to be
inconsistent. It treats \j as literal "j" and ignores non-hex numbers inside
\x{} (though it warns if you turn warnings on) but any mistake with \o{} causes
an error. Anyway, I have now implemented a new option
PCRE2_EXTRA_BAD_ESCAPE_IS_LITERAL. This is documented as a "dangerous option,
use with care". It causes any kind of parsing error for an escape sequence to
become an escaped literal. So OK, I've changed my mind about what I said
previously.
Rewriting the escape handling function was not the way to do this, because some
escape parsing, e.g. handing \g{name} happens afterwards. However, the patch is
not very big. I have now committed it, with documentation and tests, to the SVN
repository, so it will be in the 10.30 release (expected around August), but
you can get the current code from the repo now if you want it.
--
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
