Re: [pcre-dev] [Bug 2106] Please add support for parsing POS…

Top Page
Delete this message
Author: zatlas1@yahoo.com
Date:  
To: admin@bugs.exim.org, pcre-dev@exim.org
Subject: Re: [pcre-dev] [Bug 2106] Please add support for parsing POSIX basic & extended regular expressions
I have had a similar problem in my port to z/OS.I am not near my computer but I will try to share my solution tonightZA

Sent from Yahoo Mail on Android

On Wed, May 17, 2017 at 1:20 PM, admin@???<admin@???> wrote: 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.
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev