On Sun, Sep 07, 2003 at 06:23:04PM +0100 Nick Ing-Simmons wrote:
> Jan Dubois <[EMAIL PROTECTED]> writes:
> >On Sun, 07 Sep 2003 09:49:32 +0200, Tassilo von Parseval
> ><[EMAIL PROTECTED]> wrote:
> >> SV * call_Pslice (const char *func) {
> >> SV *res;
> >>
> >> dSP;
> >> ENTER;
> >> SAVETMPS;
> >> PUTBACK;
> >>
> >> (void)call_pv(func, G_SCALAR);
> >> SPAGAIN;
> >>
> >> res = newSVsv(POPs);
> >>
> >> PUTBACK;
> >> FREETMPS;
> >> LEAVE;
> >>
> >> return sv_2mortal(res);
> >> }
> >
> >You are missing a PUSHMARK(xxx) call in here. The call_pv() will pop your
> >callers frame from the stack, and you caller doesn't seem to adjust for
> >it.
> >
> >Two more unrelated notes:
> >
> >1) You call sv_2mortal() on your result without checking if the result has
> >the SvREADONLY bit set. If the sub can return undef, you may be modifying
> >the refcount of an immortal, which doesn't matter in most cases as it
> >starts with a refcount of 2**31, but is still bad style (IMO).
>
> I am not that bothered by that style issue. A related issue
> is that the value POPs-ed was a return value which would have been just
> fine a 'res' - if you removed the SAVETMPS/FREETMPS which will free it.
Initially I did it like that. Got rid of the FREETMPS and just returned
what POPs gave me. But because I had troubles with the return value
randomly disappearing, I blamed it on this so I scratched it.
But now I can put it in again, as some tests have shown. :-)
I was once more thinking about this PUSHMARK/PUSHBACK issue. perlapi.pod
described them as "opening" and "closing" brackets for the arguments. If
I leave those off altogether, shouldn't then simply the current @_ be
passed on to the callback? This would be extremely handy in my case
since the arguments for the callback are exactly those of the XSUB
originally called. Therefore, I shouldn't need to re-populate @_ (at
least not in theory).
It worked like this for the callback that did not modify $_[0], but not
properly for the other one.
> >2) Calling call_xxx() without G_EVAL often doesn't work correctly when
> >your Perl sub can die(). Maybe it is just cargo cult, but I've been
> >bitten by this one too many times and now always specify G_EVAL and check
> >SvTRUE(ERRSV) myself to handle exceptions myself.
>
> This has (I think) finally been fixed - but only recently.
> Stick with the cargo-cult for portability.
Ok, I take your word on that and change things accordingly. Tests with
5.8.1, 5.6.1 and 5.00503 suggested that they all behave identical, but
those weren't very complicated callbacks that I used.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
