i'm fairly certain about the behaviour being correct, despite the fact that even the current version of PHP seems to get it wrong! what i shouldn't have been sure about, and i apologize if it misled you, was the solution i proposed at the end of my original post. in truth, the next position mIRC should try cannot be determined solely by the original start offset and ovector[0]/[1].
for example, given the string "aa" and an original offset value of 0:
- the expression /a\K/g results in {1,1} returned in the ovector, but the correct move is to re-try the pattern at position 1.
- the expression /(?<=a)/g also results in {1,1} returned, but the correct move in this case is to move to position 2, since it will match the same 'a' again if kept at position 1.
man.txt has some advice regarding this issue:
Finding all the matches in a subject is tricky when the pattern can
match an empty string. It is possible to emulate Perl's /g behaviour by
first trying the match again at the same offset, with the
PCRE_NOTEMPTY_ATSTART and PCRE_ANCHORED options, and then if that
fails, advancing the starting offset and trying an ordinary match
again. There is some code that demonstrates how to do this in the pcre-
demo sample program. In the most general case, you have to check to see
if the newline convention recognizes CRLF as a newline, and if so, and
the current character is CR followed by LF, advance the starting offset
by two characters instead of one.
so when you try it again with those flags enabled, /(?<=a)/ causes a failure whereas /a\K/g succeeds but this time the vector returned is {2,2}. i haven't seen the demo code, but i assume the method is:
- if previous call returned {N,N}, try the next match at offset N with both PCRE_NOTEMPTY_ATSTART and PCRE_ANCHORED enabled, and flip a switch.
- if the match failed and the switch is on, try again at offset N+1
- if the match succeeded, go back to step 1
