[pcre-dev] [Bug 2106] Please add support for parsing POSIX b…

Top Page
Delete this message
Author: admin
Date:  
To: pcre-dev
Subject: [pcre-dev] [Bug 2106] Please add support for parsing POSIX basic & extended regular expressions
https://bugs.exim.org/show_bug.cgi?id=2106

--- Comment #3 from Kyle J. McKay <mackyle@???> ---
I look forward to the release of that functionality. :)

I'm coming at this from the point of view of wanting a drop-in replacement (at
the source code level -- in other words a recompilation is required but no
source code changes) for system-level POSIX-compatible regex.h functions
(preferably including support for the *BSDism extensions REG_STARTEND, REG_PEND
and REG_NOSPEC which are mostly trivial to do with PCRE2; REG_NOSPEC makes the
pattern "fixed" like fgrep and I'm not sure there's something for that in
PCRE2).

I was thinking that overhauling pcreposix.h might be the way to go, but perhaps
not. If pcreposix stays the way it is now -- providing exclusively PCREs via a
POSIX-similar regcomp/regexec API, with the release of the new pattern
translation functions it would be relatively easy to create a new
"pcre/regex.h" header and associated pcreregex.c file to make a new
libpcreregex.a library that provides a 100% POSIX-compatible drop-in
replacement for the system's regex.h with POSIX-compatible extensions such as
the *BSDisms and REG_PCRE/REG_JAVASCPT options.

The benefit of this approach is that the learning curve is basically zero to
switch away from a possibly pathological system regex implementation while at
the same time optionally adding PCRE support.

If the code already uses POSIX extended regexes via the regex.h header and
REG_EXTENDED (perhaps with the *BSDism REG_STARTEND/REG_PEND extensions so as
not to worry about NULs) one simple replacement of "REG_EXTENDED" with
"REG_PCRE" in the code and suddenly you've got PCREs -- no new API to learn.

I realize that pcreposix already provides this, but not if you also need BRE
support or need simultaneous BRE/ERE and PCRE support (as would be required to
replace the system's POSIX regex.h).

Eliminating/reducing the learning curve is a good thing because it seems that
no matter what the circumstance, when adding new features one thing always
remains the same, there is never enough time.

--
You are receiving this mail because:
You are on the CC list for the bug.