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

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

Thread Previous | Thread Next
October 19, 2016 21:29
Re: [perl #129903] regexec.c stack overflow
Message ID:
On 19 October 2016 at 22:51, Father Chrysostomos via RT
<> wrote:
> On Wed Oct 19 00:23:19 2016, demerphq wrote:
>> On 18 Oct 2016 23:46, "Father Chrysostomos via RT" <
>>> wrote:
>> > PL_curpm does far too many things.  This is not the only bug that results.
>> Can you expand on that thought a bit please?
> Having PL_curpm point to the actual pattern in the op tree results in different recursion levels sharing the same set of match variables:
> $u = ",echle etn sJ";
> $t = "\nrka rPrhoatu";
> $_ = $u.$t;
> sub foo { s/(.)//s or return; bar(); print chop $$1 }
> sub bar { s/(.)//s or return; foo(); print chop $$1 }
> foo
> (I thought I had reported this before, but I cannot find the ticket now.)

Wow. It took me a while to work that through. :-)

I see what you mean. That is going to be a lot harder to fix than the
other issues with PL_curpm IMO.

> Using a qr// works.
> Similarly, having m|(?{ // })| try to use the *current* pattern instead of the last pattern to match successfully—solely due to an implementation detail—seems wrong.

Yes I agree.

> PL_curpm is serving three purposes: the last match op, the last set of matched buffers ($1 etc.), and the innermost pattern enclosing the currently executing code.

Yes, I see what you mean. I think I might have put it differently, but
i get your point now for sure.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About