Steve Hay <[EMAIL PROTECTED]> writes:
>>
>>PUSHi et. al. are core perl utils and (most) perl ops have a TARG SV
>>
>I was puzzled by the difference with PUSHs(), that's all. Are you
>implying that PUSHs() is not a core Perl util, or just that it happens
>to be one that doesn' t have a targ SV?
Well obviously core perl does use PUSHs()
Not least because PUSHi calls PUSHTARG which does PUSHs
These macros were created for the core...
>>
>>(Devel::Leak may help here.)
>>
>Nice little module. (Why can't it do dumps unless you have a DEBUGGING
>Perl? Just removing
>
>#ifndef DEBUGGING
>#define sv_dump(sv) PerlIO_printf(PerlIO_stderr(), "\n")
>#endif
>
>from Leak.xs lets it produce SV dumps with my "release" build Perl...)
Once upon a time sv_dump() didn't exist unless you had -DDEBUGGING.
>
>Anyway, Devel::Leak says that there are no leaks.
Fine.
>
>However, it seems that I've taken my eye off the ball with all these
>compilation problems and concerns over memory leaks: the
>PUSHi()/PUSHp() version of the XSUB above doesn't actually work properly!
>
>Instead of returning (42, "Forty-two"), it returns ("Forty-two",
>"Forty-two"). In general, if I use PUSHi() or PUSHp() to push N things
>onto the stack and then XSRETURN(N) then I seem to get N copies of the
>last return value that I pushed.
Only one TARG SV for the op. If you look at macros in pp.h
you will see
PUSHi(i) STMT_START { sv_setiv(TARG, (IV)(i)); PUSHTARG; } STMT_END
So it sets the one SV to the value, and then pushes the one SV.
So it seems that PUSHi() et. al. are not suitable for list returns.
Given that
#define PUSHs(s) (*++sp = (s))
You/we would have to build a new macro heirachy:
#define PUSHmortal PUSHs(sv_newmortal())
#define mPUSHi(i) sv_setiv(PUSHmortal(),(IV)(i))
Snag here is we must be very carefull that the '++sp' etc. does
not get evaluated more than once. Static/inline functions
would be cleaner if somewhat alien to perl's normal coding style.
