https://bugs.exim.org/show_bug.cgi?id=2107
--- Comment #1 from Philip Hazel <p...@hermes.cam.ac.uk> --- My view is that converter functions are the best approach here, rather than cluttering up the PCRE API with yet more options and the code with yet more special cases. (This is similar to a previous request for "Please add a way of handling invalid UTF strings", which I'm sure are better handled by a separate function that turns them into valid strings for processing.) I guess glob is quite easy: * becomes .* and ? becomes . and all other PCRE metacharacters get escaped and (?s) gets set (so . matches newlines). Is that it, or have I missed something? I'll think about this. As it happens, I've just finished a big update on the pcre2_match() interpreter for the next release. (It uses heap, not stack, and is a bit faster, but shouldn't affect you as I know you are using JIT.) I don't want to put out a new release just yet because I don't like to burden the downstream maintainers more than every six months (10.23 was released in February). So there's time to consider new (not too enormous) features. -- 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
