Front page | perl.perl5.porters |
Postings from August 2010
On Aug 4, 2010, at 7:27 AM, demerphq wrote:
> On 4 August 2010 15:47, karl williamson <public@khwilliamson.com> wrote:
>> demerphq wrote:
>>>
>>> On 1 August 2010 21:19, Father Chrysostomos <sprout@cpan.org> wrote:
>>>>
>>>> A slightly simpler case:
>>>>
>>>> $ perl -le '$_="CCCGGG"; s!.!@a{print("[$&]"),/./}!g'
>>>> [C]
>>>> [C]
>>>> [C]
>>>> [C]
>>>> [C]
>>>> [C]
>>>>
>>>> What’s happening is that the s/// does not reset PL_curpm for each
>>>> iteration, because it doesn’t usually have to.
>>>>
>>>> The RHS’s scoping takes care of it most of the time. This happens with
>>>> the /e modifier and with @{...}.
>>>>
>>>> In this example, though, we have a subscript, not a block. This subscript
>>>> is in the same scope as the s/// itself.
>>>>
>>>> The assumption that the substitution operator will never have to reset
>>>> PL_curpm itself appears to be incorrect. The attached patch fixes it.
>>>
>>> Hi, thanks for the patch. Im a little concerned that this might have
>>> deeper consequences than at first meet the eye, could we hold off on
>>> this one until we know more?
>>
>> How will we find out more?
>
> The problem is that there is a lot of code around that tries to deal
> with various logical inconsistancies related to qr// and PL_curpm, and
> the code is not obvious or intuitive.
>
> So, for instance I am wondering what happens with this patch and
> things like recursive patterns on the LHS, or things like that.
>
> PL_curpm and everything related to it really deserves some deep
> analysis and some love.
Could you explain to me what the two PL_curpm assignments in regexec.c are for? One is in S_regtry; the other in restore_pos. When are those two functions called?
(All other assignments to PL_curpm look fine to me and do not conflict with the patch.)
Thread Previous
|
Thread Next