On Fri Sep 27 03:34:02 2013, LeonT wrote: > On Thu Sep 26 03:49:32 2013, ruslan.zakirov@gmail.com wrote: > > I had to grep cpan to understand what to do to avoid freeing. Still > > not shure if it's ok to call SvREFCNT_inc(POPs) or if it has to be > > newSVsv(POPs). If former then example should use most effective > > variant of SvREFCNT_inc*. > > POPs should never be used in a macro that can evaluate it multiple > times. You want to pop it into a variable when passing it to any macro > (such as SvREFCNT_inc) and you may or may not have to un-temp it after > doing SvREFCNT_inc. newSVsv would be a more foolproof approach. AFAIK, to get an SV returned from a call_* to live past the FREETMPS, a SvREFCNT_inc is the solution. But, I thought of another situation, what if a DESTROY in a blessed SV being freeded in FREETMPS die()s? The SV* that got a ++ to live past the FREETMPS leaked. The newSVsv solution also leaked. -- bulk88 ~ bulk88 at hotmail.com --- via perlbug: queue: perl5 status: open https://rt.perl.org/Ticket/Display.html?id=120017Thread Previous | Thread Next