Front page | perl.perl5.porters |
Postings from January 2005
Re: /(?{...})/ bug?
Thread Previous
|
Thread Next
From:
Dave Mitchell
Date:
January 28, 2005 17:51
Subject:
Re: /(?{...})/ bug?
Message ID:
20050129015158.GF5370@iabyn.com
On Fri, Jan 28, 2005 at 10:17:51PM +0000, Dave Mitchell wrote:
> On Fri, Jan 28, 2005 at 09:40:30PM +0100, Torsten Foertsch wrote:
> > I expect the program below to print "klaus" three times. But it prints only
> > one "klaus". If I change the "my $pos=pos" to "$pos=pos". It works as
> > expected. Is that a bug? Or is it documented somewhere?
>
> it can be reduced to the following code:
>
> my $s="a a a a a";
> $s=~ m{ (?{ my $x = 1; }) }x;
> use Devel::Peek;
> Dump($s);
I've found the cause. It's yet more (?{}) brain-damage. Each entry to a
block temporarily introduces a different pad, but doesn't introduce a new
scope(*). During execution of the block, the 'my $x' pushes a
SAVEt_CLEARSV onto the savestack. On exit from the block, PL_curpad is
restored to the old pad, but the savestack isn't yet popped. On final exit
from the regex, the savestack is popped, $x is freed, but by now the
parent pad is in use, so $s gets freed by accident.
I can't see a quick fix for this, though it should disappear in the wash
if I ever manage to finish off my (?{}) rewrite for 5.10
I'm quite astonished at how serious a bug this is. It basically boils down
to: any declaration of a lexical within a (?{}) may corrupt an outer
lexical or pad tmp.
Dave.
(*) This behaviour is documented in Camel III: local() within a (?{})
doesn't undo at the end of the block, rather it undoes at the the end of
the regex. It's never been clear to me whether this was deliberate,
desired behaviour, or just a side-effect of the implementation. Personally
I dislike it.
--
A power surge on the Bridge is rapidly and correctly diagnosed as a faulty
capacitor by the highly-trained and competent engineering staff.
-- Things That Never Happen in "Star Trek" #9
Thread Previous
|
Thread Next