On 04/28/2015 06:40 AM, demerphq wrote: > On 28 April 2015 at 13:14, <ph10@hermes.cam.ac.uk> wrote: >> On Mon, 27 Apr 2015, James E Keenan via RT wrote: >> >>>> I think this is a similar bug to the one I have just >>>> fixed in PCRE. >>>> >>> >>> Can you provide a link to that fix? >>> >>> Thank you very much. >> >> Not very easily (I'd have to check the SVN manual to figure out how to >> search for stuff - I'm a very simple user) and in any case the fix was >> different for PCRE1 and PCRE2. The bug was in the test programs pcretest >> and pcre2test rather than in the library itself (which only does single >> matches). Here is a comment from pcre2test.c: >> >> However, even after matching a non-empty string, there is still one >> tricky case. If a pattern contains \K within a lookbehind assertion at the >> start, the end of the matched string can be at the offset where the match >> started. In the case of a normal /g iteration without special action, this >> leads to a loop that keeps on returning the same substring. >> >> The code now checks for this case and advances the /g loop by one >> character, just as it does for matching an empty string. > > Sounds like we have the same problem in Perl. > > Karl, if you dont see a way to fix this then let me know and I will pick it up. > > Cheers, > yves > > I haven't ever looked at the \K code; I was hoping someone else would look at this.Thread Previous | Thread Next