develooper Front page | perl.perl5.porters | Postings from December 2010

Re: [perl #19135] string eval turns off readonlyness on lexicals

Thread Previous | Thread Next
From:
Dave Mitchell
Date:
December 6, 2010 07:39
Subject:
Re: [perl #19135] string eval turns off readonlyness on lexicals
Message ID:
20101206153941.GI2685@iabyn.com
On Sun, Nov 28, 2010 at 01:39:18PM -0800, Father Chrysostomos via RT wrote:
> On Sun Sep 26 12:46:49 2010, sprout wrote:
> > On Sun Sep 19 12:10:11 2010, sprout wrote:
> > > The readonliness is turned off explicitly in pad_free under ithreads.
> > >    See also bug #19022, which resulted from the same change. There is
> > >    some discussion there, too, but nobody seemed to know exactly why
> > >    the readonliness needed to be turned off.
> > > 
> > > Change 4761/2aa1bed, from January of 2000, added that SvREADONLY_off.
> > >    It is supposed to make sure that pad entries that were constants
> > >    will not be constants the next time they are used.
> > > 
> > > My question is: When the addresses of those scalars are reused, won’t
> > >    the scalars be wiped clean? (In case it’s not obvious, I have very
> > >    little idea how pads actually work.)
> > > 
> > > I tried simply deleting that SvREADONLY_off, and all tests pass (see
> > >    the first attached patch).
> > > 
> > > Then I thought that maybe I should check that the SV is freed, and
> > >    only then do SvREADONLY_off, to preserve the original intent of
> > >    change 4761/2aa1bed. That worked too.
> > > 
> > > So, here are two patches. Take your pick.
> > 
> > Has anyone in the know had a chance to review these yet?
> 
> Well...? :-)
> 
> Here is a better test case, with no Internals:: stuff:
> 
> $ perl5.13.5 -wle 'for my $k(!0) { eval "\$k"; eval { $k = 7 }; print
> "a"=~/a/ }'
> 7

I think the first fix is correct (just removing the SvREADONLY_off).
The issue it was trying to fix appears to have been properly fixed later
by 3b1c21fabed159100271bd60bac3f870f5ac16af, which is why it's safe to
remove it.

The second fix is wrong, in that the SVs in the pad aren't freed in the
RC==0 sense, but instead are left available for new ops (so when during
compiling, an op and its targ are optimised away, that slot (and the
same SV) will get reused). The RO flag is part of the criteria to decide
whether a pad slot is available ("free") for re-use (IS_PADCONST).

-- 
Thank God I'm an atheist.....

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About