https://bugs.exim.org/show_bug.cgi?id=2211
--- Comment #3 from Philip Hazel <[email protected]> --- (In reply to John Tattarakis from comment #2) > I'm glad you got it working, and will encourage mIRC's Khaled to update to > PCRE2 to resolve this and similar errors. If you have a moment, could you > clarify where this handling has been added to pcre2demo? I think I'm looking > at the correct page (https://www.pcre.org/current/doc/html/pcre2demo.html) > but I can't find any differences there or added documentation as compared to > pcredemo in the way that empty matches are found. Mea culpa. I forgot to run the documentation update script, which makes the HTML from the man pages and from the pcre2demo source, before I committed. Now done. The pcre2demo.3 doc and the equivalent HTML should now be updated. > https://pastebin.com/D8PsAdQzdoc/ > > The logic here is that ovector[0] should play no part in deciding the > position of the next start_offset since it could have been distorted by the > user. Basically, the application should look at the positions where > successive matches are _ending_ in order to determine whether an empty > string was matched or not. Is this logic flawed? I think it is flawed (but it is entirely possible that I am flawed :-). The flaw is that the example you gave (?<=\K.) does not result in an empty string match. Thus, setting PCRE2_NOTEMPTY_ATSTART for the next try won't work. -- 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
