in reply to
Re^2: xs modifying passed value
in thread xs modifying passed value
I don't really know C++, that is C++ code. Can you post the function from the .c file that xsubpp generates from your XS syntax func?
I suggest you use Devel::Peek's Dump function. You can also call it from XS/C as dump.c#l2139 in perl.git as "void sv_dump(SV *sv)" It will need a SV *, I think that ST(1) is the passfail param as a SV *, since ST(0) will be your THIS pointer in a SV * I think from Script land. Using sv_dump with your code unmodified is impossible as written since the setting of SV * that matches passfail is after your CODE: section (again look at the .c file produced), so you would need to
SvSetMagicSV(passfailSV, passfail ? &PL_sv_yes : &PL_sv_no);
I think there is a bug in the typemap,
$arg = boolSV($var);
That is from the default typemap. But look at boolSV.
=for apidoc Am|SV *|boolSV|bool b
Returns a true SV if C<b> is a true value, or a false SV if C<b> is 0.
See also C<PL_sv_yes> and C<PL_sv_no>.
#define boolSV(b) ((b) ? &PL_sv_yes : &PL_sv_no)
We assigned a SV * to a SV *, but if this is a in parameter and not an out parameter, you can't just change the SV * to another SV *, you have to change the SV * you got from the caller (return/result's of XSUBs are *usually* brand new SV *s you created and mortalized, then boolSV would work, it won't work to change the inside value of an existing scalar). BTW, you never need to mortal in SV *s you get through the param list (AKA ST(123456) macros), your caller owns the param list SV *s. Also never mortal &PL_sv_yes, &PL_sv_no, &PL_sv_undef, they are process globals/statics.
I probably should go file a bug report with ExtUtils::ParseXS
but I dont have the time.
update: bug filed