https://bugs.exim.org/show_bug.cgi?id=2106
--- Comment #4 from Philip Hazel <p...@hermes.cam.ac.uk> --- (In reply to Kyle J. McKay from comment #3) > > 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). REG_STARTEND is already there. As you say, REG_PEND is probably easy to do. There is no PCRE2 equivalent for REG_NOSPEC. Using a pattern matching engine to search for fixed strings is horribly inefficient. There are nice fast algorithms for doing that. Somebody should write a library if there isn't one already. > > 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. ...with one difference. PCRE2, like Perl, returns "first match" (at a given point in the subject string), whereas POSIX mandates "longest match". However, I have just in the last few days (while thinking about all this POSIX stuff) realized that the newly-refactored matching function (not yet released, but coming soon) probably makes it possible to provide "longest match" functionality, but at a computational expense, of course. I intend to look into this once the flurry of existing issues is past. > > 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. That is certainly true! -- 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
