https://bugs.exim.org/show_bug.cgi?id=2106
--- Comment #5 from Kyle J. McKay <mack...@gmail.com> --- > REG_STARTEND is already there. Except that it's not *BSD compatible -- see bug #2128 > 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. Hmmm, "write a library"... Sounds like PCRE... ;) When I added support for REG_NOSPEC I used PCRE_VERBATIM as the new option and just force the pattern compiler to start in "\Q" mode and then arrange for any embedded "\E" to NOT get recognized. I think it was the easiest one of all to add. I might expect matching a fixed pattern like "abcabcz" against a string like "abcabcabcabcabcz" to not be handled all that efficiently by a naive strstr (or memmem) implementation, but I'd expect a pattern matching engine to do better. There's also the matter of REG_NOSPEC | REG_ICASE | REG_UTF8 probably working much better, more conveniently and more reliably via PCRE than using the standard library's strstr + something for the REG_ICASE part and handling REG_UTF8 properly. (With REG_UTF8 does PCRE perform virtual NFC cannonicalization while matching so, for example, a decomposed e+accent matches the precomposed e+accent version? I'm thinking it probably does...) In any case, a wrapper that wants to implement REG_NOSPEC can just kludge it up with calls to strstr/memmem or producing a malloc'd duplicate starting with \Q and escaped \E (which is \E\\E\Q BTW) replacements -- I don't see why the pattern translator can't do that itself though in order to provide a REG_NOSPEC option. -- 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