Nick Ing-Simmons wrote:
>Steve Hay <[EMAIL PROTECTED]> writes:
>
>
>>>(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.
>
So perhaps
#ifndef sv_dump
#define sv_dump...
#endif
would be better?
>
>
>>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.
>
Argh! (Or maybe "Arg!")
>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.
>
I can't see that ++sp does get done more than once in what you have above.
This code builds and runs OK (and still doesn't leak either):
#define PUSHmortal PUSHs(sv_newmortal())
#define mPUSHi(i) STMT_START { sv_setiv(PUSHmortal, (IV)(i)); } STMT_END
#define mPUSHp(p, l) STMT_START { sv_setpvn(PUSHmortal, (p), (l)); }
STMT_END
void
baz()
PPCODE:
{
EXTEND(SP, 2);
mPUSHi(42);
mPUSHp("Forty-two", 9);
XSRETURN(2);
}
I'd be quite happy to finish off this new set of mPUSH*() macros and
post a patch off to p5p if you think it's worth it (unless you'd rather
do it yourself)?
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender immediately. The
unauthorized use, disclosure, copying or alteration of this message is strictly
forbidden. Note that any views or opinions presented in this email are solely those
of the author and do not necessarily represent those of Radan Computational Ltd. The
recipient(s) of this message should check it and any attached files for viruses: Radan
Computational will accept no liability for any damage caused by any virus transmitted
by this email.
