Front page | perl.perl5.porters |
Postings from October 2016
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. :-)
Yves
Thread Previous
|
Thread Next