🚀 go-pugleaf

In article <4l33l8$7of@solutions.solon.com> mfg@ee.edinburgh.ac.uk (Michael F Gordon) writes:
>Another place where I've found alloca() very useful is to allocate
>memory in a recursive descent parser for a simple calculator.
>Instead of cluttering the code with error checks at every step and
>having to free memory and pass error values back up the calling
>chain, I just longjmp'd back to the top level parse() function
>whenever one of the low level routines found an error.
>
>So, just how non-portable and horrible is this?
>
Different implementation have varing "flavours" of alloca
1) It may not exist.  It is after all NOT required by the C standard.
   You clearly are not portable to these implementations.
2) It exists and works by playing games with the stack frame size.
   Your technique will not work on implementations where there
   are tight limits on frame size or total stack space.
   Fixing a maximum total stack at compile/link time is not
   uncommon.  And being able to extend the function framesize
   dynamically usually requires the calling sequence to sacrifice
   a register.
3) It exists, but works by calling malloc(), and arranging a hidden
   free() on return.  Your technique will only work on those
   implementations where longjmp() also looks after these hidden
   free() calls.

How portable do you want to be?  What range of machines do you want
to support?