in reply to Re^4: When to (and not to) use sv_2mortal()
in thread When to (and not to) use sv_2mortal()
patcat88 Thank you for taking me at my word and taking the time to post this. I am still, and possibly always destined to be, nothing more than a neophyte XS dabbler; a needs-must source diver; and a reluctant visitor to those worlds. There are many reasons for this, but primary among them is the lack of good feedback on the subject.
I do not yet understand all of what you've said, so I will need to re-visit it till I do. To that end, I am re-posting your content below having applied a little formatting, as I found the combination of its density and my tired eyes too hard to read, and I don't want to have to reformat it every time I revisit it.
I'm talking about the above. Original author even says its intended to be a replacement for alloca.
Also, someone correct me if I'm wrong, but I've read rumors in Perl's source that SVs can "steal" the strings/PVs of other SVs leaving the source SV undefined.
I've seen it on defelem 'y' magic SVs that come in on the Perl Stack. The mess in sv_setsv sv.c#l4227 in perl.git does, sometimes, maybe, steal the PV from source to destination SV.
I guess some programmers might be intentionally taking advantage of the fact that mortalized SVs can give up their PVs to a destination SV.
For example, in an XSUB with C style data return in parameter scalars, if the C func fails, dont touch the value of the parameter Perl Stack SV, let the mortal SV disappear in the return, or in the croak.
The author of Win32API::File obviously isn't doing that since the SV * is tossed leaving only the char */PV around.
Remember (not to you BrowserUk), croaks in XS and dies in Perl are implemented using a Perl Stack unwinder (will call DESTROY if objs), and a C Stack unwinder (setjmp/longjmp).
If you malloc a block (or new anything in C++), callback into Perl without eval protection and the CV dies, you just leaked memory.
Using the sv_grow/mortal macro above would give you a croak safe C++ smart pointer in XS, using alloca would too.
The magic system can also cause you to run Perl unintentionally in XS. Not sure if the magic system sets up an eval catch or not if the C func or Perl sub croaks/dies in the magic setter/getter.
Not sure what else in the XS/C perl api can croak other than magic SVs and callbacks into Perl.
The definition of mortal should be "the caller shall delete the SV if the caller shall not need it when the callee returns to the caller".
The warnings about needing to return to Perl or ENTER/LEAVE blocks in perlguts or whereever it is still stands,
AKA, never make mortal SVs in a non hard coded iteration loop (while(i<10) is good, while(i<runtimes), while(!exit), while(job = oldjob->Next) is very bad).
You'll run out of memory/ "C stack overflow" (but its not a C stack overflow, its heap memory you ran out of).
Can you think of any other uses of mortal system? :-)
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.