Front page | perl.perl5.porters |
Postings from April 2015
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. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next