Steve Hay <[EMAIL PROTECTED]> writes:
>>
>>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?
Yes.
>>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.
Neither could I - but didn't want to commit myself without
having tried it.
>
>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)?
If p5p members reading this want to comment now is time for
them to do so - I quite like the idea.
>
>- 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.
