https://bugs.exim.org/show_bug.cgi?id=2106
Kyle J. McKay <mackyle@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mackyle@???
--- Comment #1 from Kyle J. McKay <mackyle@???> ---
Ãvar pointed me to this change request and suggested I mention some of the work
I've done.
Git bundles a regcomp/regexec implementation (from glibc) to provide POSIX
Basic Regular Expresion (BRE) and POSIX Extended Regular Expression (ERE)
support. This bundled implementation often ends up being used (various
reasons) even when the platform has its own regcomp/regexec implementation.
The bundled implementation has some unfortunate performance issues with some
pathological regexes that I prefer to avoid.
Since I build PCRE anyway for Git (Git also optionally supports PCREs) I wished
to use PCRE to provide BRE and ERE support as well (thereby avoiding the
bundled glibc code) since PCRE does not exhibit the problematic pathological
behavior.
To this end I created a few patches for PCRE-8.40 (support for PCRE2 is not yet
part of a Git release) mainly aimed at the pcreposix functionality so that
pcreposix.h can support all of:
1) POSIX BREs (with no flags)
2) POSIX EREs (with REG_EXTENDED flag)
3) PCREs (with new REG_PCRE flag)
4) JREs (with new REG_JAVASCPT flag)
These patches are available in the Git repository at:
https://github.com/mackyle/pcreposix-compat
The default branch (pcreposix-compat) contains the expanded PCRE-8.40 tarball
with the patches already applied and can be "configure"d and "make"d.
However, the pcreposix-compat-patches branch contains just the changes as
individual patch files (in the patches subdirectory) and can be easily viewed
at:
https://github.com/mackyle/pcreposix-compat/tree/pcreposix-compat-patches/patches
The patches provide pattern-compile-time-only changes to support BREs and EREs
-- the incoming BRE/ERE is virtually rewritten into an equivalent PCRE while
it's being compiled.
No changes to the underlying matching engine are needed whatsoever. It's just
all "syntactic sugar" at pattern compile time.
I suspect it wouldn't be all that difficult to add similar support to PCRE2.
--
You are receiving this mail because:
You are on the CC list for the bug.
