https://bugs.exim.org/show_bug.cgi?id=2030
--- Comment #3 from Philip Hazel <p...@hermes.cam.ac.uk> --- No, you are right. I had thought about this some more myself, and came to the same conclusion. I will add a new option (called PCRE2_ENDANCHORED unless I can think of something better) that causes the match to fail (and therefore backtrack) if the end of the pattern is reached before the end of the subject. Using this with PCRE2_ANCHORED should give the result you want. I will add this as an option that, like PCRE2_ANCHORED, can be used at compile time or match time, but I suspect that (again like PCRE2_ANCHORED) using it at match time will disable the use of JIT. However, this will not be for some time. Once 10.23 is released (in a couple of weeks' time) and has settled for a week or two, I will get on with integrating a new version of pcre2_match() that I have been working on. This uses the heap for backtracking instead of the stack, but in a more efficient way than the existing --disable-stack-for-recursion option (in fact, it seems to run about 10% faster than the current non-heap code). That will take time, as there is a lot of documentation and other associated stuff to update, but as 10.23 is coming out in February, I won't be planning on another release till around August at the earliest. As well as getting rid of "stack exceeded" errors, which have been a source of irritation since the start of PCRE, the new pcre2_match() also fixes at least one obscure bug, and allows for backtracking into recursions such as (?2) which makes it more Perl-compatible. And the code has had a useful clean-up. -- 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