Front page | perl.perl5.porters |
Postings from October 2016
On 19 October 2016 at 22:51, Father Chrysostomos via RT
<perlbug-followup@perl.org> wrote:
> On Wed Oct 19 00:23:19 2016, demerphq wrote:
>> On 18 Oct 2016 23:46, "Father Chrysostomos via RT" <
>> perlbug-followup@perl.org> 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.
Yves
Thread Previous
|
Thread Next