Re^2: XS debugging "failed to extend arg stack"

I've come to the conclusion that you've hit an unfortunate case - the EXTEND macro evaluates its arguments several times

It sounds like you're saying that's the problem, but it took a a few reads to realize this isn't actually a problem here. The actual problem is the fact that the macro and the caller both use a var named ix.

NERDVANA said,

A good reminder to not use expressions inside macros.

The relevant lesson is to not use variable names in macros that could possibly be used outside the macro.

Comment on Re^2: XS debugging "failed to extend arg stack" Download Code

Replies are listed 'Best First'.
Re^3: XS debugging "failed to extend arg stack" by hv (Prior) on Jun 03, 2022 at 16:59 UTC
Yes, I probably didn't express myself as clearly as I could have done. Of course _any_ variable name "could possibly" be used outside a macro: macros don't come with much by way of safety features. I've been suggesting for a while that we should replace as many as we can with inline functions - which also gives type safety (as much as C has, at least), and protects against repeated evaluation of arguments - but for reasons which escape me there seems little enthusiasm for such a change. (I briefly considered suggesting I should write an essay "macros considered harmful", but then I read Considered harmful and thought better of it.)	[reply]
Re^4: XS debugging "failed to extend arg stack" by Anonymous Monk on Jun 04, 2022 at 04:32 UTC
I'd love to see the C preprocessor replaced by Perl. :-). maybe perl itself could pioneer that pattern? Compile microperl, then use microperl as the preprocessor for the c code of main perl.	[reply]
Re^3: XS debugging "failed to extend arg stack" by NERDVANA (Priest) on Jun 03, 2022 at 16:58 UTC
And especially since I didn't decide to name the variable 'ix'. 'ix' is defined by the xs tooling in any Perl xsub which uses aliasing, and the EXTEND macro is only used in xsubs anyway. So it's a natural name collision.	[reply]