https://bugs.exim.org/show_bug.cgi?id=2211
--- Comment #3 from Philip Hazel <ph10@???> ---
(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.
