Front page | perl.perl5.porters |
Postings from October 2016
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.
--
Father Chrysostomos
---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=129903
Thread Previous
|
Thread Next