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

"\" ref op and newRV are different, y magic

Thread Next
From:
Patcat88
Date:
December 6, 2011 17:43
Subject:
"\" ref op and newRV are different, y magic
Message ID:
4EDEC49E.3000601@snet.net
I am writing in regard to this post I made on PerlMonks at 
http://perlmonks.org/?node_id=941973 . newRV 
http://perl5.git.perl.org/perl.git/blob/HEAD:/sv.c#l8654 and the Perl 
langauge ref operator ("\") 
http://perl5.git.perl.org/perl.git/blob/HEAD:/pp.c#l501 have completely 
different behavior. When an XSUB gets a TARG SV or a fake hash array 
slice ('y' magic), it has no way of knowing that those SVs can not have 
references created to them, or refcount-saved for later use. SvPADTMP 
and IS_PADGV are not part of the Public API. 'y' magic is another 
problem. Currently SvSETMAGIC copies data from the fake SV to a newly 
created (at the moment) hash/array slice. LvTARG and LvTYPE aren't 
Public API either so you can't "officially" make the target SV and then 
replace the fake 'y' magic SV you got with the new real SV. A real world 
example of this design problem is in my PerlMonks post. How do I as an 
XS user, or P5P go about fixing this problem?

As I proposed on PerlMonks, why not have entersub op, if the CV is an 
XSUB and not Perl sub, go through the stack and convert all unrefable 
SVs to real SVs for the XSUBs only (newSVsv + mortal)?

Or rewrite newRV or make a newRV_flags/sv_normalize/newRV_normalize to 
do what S_refto/ref op does? Before someone says its not a problem, and 
to call

sub make_ref {
    return \$_[0];
}

from XS perlcall style, thats ridiculous IMHO.

Or just go ahead and write my own newRV_normalize that imitates S_refto 
using internal API? I must note that rewriting newRV to referize a SV 
might cause problems since existing code wouldn't update the SV * on C 
stack with the new real SV * after the unfaking. (or maybe not, since 
those XS mods would be bugging out anyway when given a TARG SV).

Or turn newRV into a macro that does "(newRV_flags(&(x))" and 
newRV_flags's prototype is "SV * newRV_flags(pTHX_ SV ** sv)" ?

 Or should newRV and possibly SvREFCNT_inc go into PAD or OP tree (right 
terms?) and swap out the TARG SV * in the PAD or OP tree with a new TARG 
SV *, turn off PADTMP flag on the ex-TARG SV * and then give the ex-TARG 
SV over to the XSUB permanently? No idea how complicated the last idea 
is but it seems least regression-ish.

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