Front page | perl.perl5.porters |
Postings from July 2013
On Fri Jul 26 23:12:23 2013, sprout wrote:
> On Fri Jan 13 13:16:42 2012, patcat88 wrote:
> > On Sun Jan 08 14:21:34 2012, sprout wrote:
> > ................................
> > > Taking a reference to $_ twice should not create references to two
> > > different variables. The implementation details are leaking through.
> > >
> > I'll add my PerlMonks discussion to this
> > http://www.perlmonks.org/?node_id=941973 . PADTMPs should always be
> > copied (or sv body stolen ??), not referenced. srefgen/S_refto and newRV
> > do different things but they should be the same. PADTMPs are supposed to
> > be allocated and dealloced on block enterance/leaving, but under the
> > hood are effectively closures or C function level static. Its a mess.
>
> This part is not resolved. I’m reopening it.
I did not fix this bug for calls to XSUBs, because it will make
Devel::Peek less useful. Calling Dump("$x") and being able to see what
pp_stringify is return is a useful feature.
(Here I’m referring to the original bug reported, not the newRV issue.
Calling foo("$x") allowed the foo sub to see a TARG in $_[0], such that
print \$_[0], \$_[0] would show two different addresses.)
Currently foo("$x") will make a COW copy of the TARG if it is a Perl
sub, but pass the TARG itself if it is an XSUB. So for XS code to call
newRV on that is wrong (or what newRV does is wrong).
I think the real solution here is to apply the fix to XSUBs (copy TARG
arguments) but modify Devel::Peek to inline itself, so that it remains
exempt.
That way the only XS code having access to TARGs will be that which
rummages through pads. For most XS code this will just dwim.
In fact, having Devel::Peek inline itself would be useful for seeing the
return value of substr and vec in rvalue context, something currently
not possible.
--
Father Chrysostomos
Thread Previous
|
Thread Next