On 4/28/2015 3:26 PM, demerphq wrote: > On 28 April 2015 at 22:28, Karl Williamson <public@khwilliamson.com> wrote: >> 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. > > Ok, then I will try to find time to address this. > Note that this is a 5.23 item, so there isn't a real urgencyThread Previous | Thread Next