On 18 Oct 2016 23:46, "Father Chrysostomos via RT" < perlbug-followup@perl.org> wrote: > > On Tue Oct 18 04:08:30 2016, demerphq wrote: > > On 18 October 2016 at 12:03, Hugo van der Sanden via RT > > <perlbug-followup@perl.org> wrote: > > > On Tue Oct 18 02:30:01 2016, demerphq wrote: > > >> I think we can fix it by checking PL_curpm against PL_reg_curpm when > > >> we do the empty pattern check; running tests now. > > > > > > And do what? Even if they're the same, it still might also > > > legitimately be the last successful match, no? > > > > No I don't think so, and all the tests pass. > > > > As far as I can tell PL_reg_curpm is a special opcode which we use > > when we are setting up PL_curpm before executing a (?{...}) or (??{ > > ... }) code block so that things like $1 and stuff like that point at > > the current pattern. Once the code is executed PL_curpm is unwound to > > no longer point at PL_reg_curpm. Essentially the problem comes down to > > PL_curpm being the place where things like $1 and friends are derived, > > as well as how we find the pattern for the last successful match, but > > inside of a (?{ ... }) we want $1 to point at the *current* pattern, > > not the *last* successfully matched one. This conflict currently > > causes use of the empty pattern in a code block to point at the > > pattern that contains the code, and trigger infinite recursion. So to > > fix this I think we would have to split PL_curpm in two, and have one > > var for $1 and friends representing "the last successful matched > > pattern or when in a regex code construct the currently executing > > pattern", and another for "last successful matched pattern" which > > would be use by the empty pattern magic. > > > > On the other hand we can simply forbid the use of the empty pattern > > inside of a regex code block and have a much simpler patch. :-) > > PL_curpm does far too many things. This is not the only bug that results. Can you expand on that thought a bit please? YvesThread Previous | Thread Next