develooper Front page | perl.perl5.porters | Postings from October 2016

Re: [perl #129903] regexec.c stack overflow

Thread Previous | Thread Next
From:
demerphq
Date:
October 19, 2016 07:22
Subject:
Re: [perl #129903] regexec.c stack overflow
Message ID:
CANgJU+VZwLPjVUXn0pf-523TECOuGTHKFkGod-x86uHEtmSWOw@mail.gmail.com
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?

Yves

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About