This resolves the last remaining issue in ticket #78194, that
newRV is supposedly buggy because it doesn’t copy its referent.
The full implications of the PADTMP are not explained anywhere in
the API docs, and even XSUBs shouldn’t have to worry about special
handling. (E.g., what if they do SvREFCNT_dec(SvRV(sv)); SvRV(sv)=...?)
So the real solution here is not to let XSUBs see them.
ext/XS-APItest/t/stmtsasexpr.t test recursive descent statement-sequence parsing
ext/XS-APItest/t/stuff_modify_bug.t test for eval side-effecting source string
ext/XS-APItest/t/stuff_svcur_bug.t test for a bug in lex_stuff_pvn
+ext/XS-APItest/t/subcall.t Test XSUB calls
ext/XS-APItest/t/sviscow.t Test SvIsCOW
ext/XS-APItest/t/svpeek.t XS::APItest extension
ext/XS-APItest/t/svpv_magic.t Test behaviour of SvPVbyte/utf8 & get magic
OUTPUT:
RETVAL
+SV *
+newRV(SV *sv)
+
MODULE = XS::APItest PACKAGE = XS::APItest::AUTOLOADtest
int
--- /dev/null
+#!perl
+
+# Test handling of XSUBs in pp_entersub
+
+use Test::More tests => 1;
+use XS::APItest;
+
+$ref = XS::APItest::newRV($_+1);
+is \$$ref, $ref, 'XSUBs do not get to see PADTMPs';
PUTBACK ;
}
}
+ else {
+ SV **mark = PL_stack_base + markix;
+ I32 items = SP - mark;
+ while (items--) {
+ mark++;
+ if (*mark && SvPADTMP(*mark) && !IS_PADGV(*mark))
+ *mark = sv_mortalcopy(*mark);
+ }
+ }
/* We assume first XSUB in &DB::sub is the called one. */
if (PL_curcopdb) {
SAVEVPTR(PL_curcop);