Re: What's wrong with alloca() ?

Our moderator writes:
> [It is my impression that there are environments where you can't reliably
> implement alloca. On non-Unix systems, you can't count on there being a
> big pool of space just beyond the stack frame, frames may be a linked list
> in random places around the address space. I do agree that something like
> it is nice to have around. -John]


On the Amiga (not under Amiga-SVR4 Unix, but under its non-Unix multi-
tasking OS--Exec?), processes are allocated a fixed stack size at startup.
A process that calls alloca() (allocating storage on the stack) and
overflows its stack could be very nasty (there is no memory
protection)--thus, the need for stack checking code.


Now, the alloca module (that some GNU programs use, eg diff v1.15) has the
advantage that it doesn't allocate storage on the stack. But, it is
sensitive to randomly located stack frames.


However, I've been using code which dynamically extends/shrinks the
program's stack, linking each stack frame to the previous one--just as
John describes--in the stack checking code. So long as the stack register
isn't used as a base register (for referencing items on the stack), it
shouldn't difficult to add an alloca() function for the compiler I'm
using. Of course, this is machine dependent, and I'll be doing it in
assembly :-)
--

Return to the comp.compilers page.
Search the comp.compilers archives again.