alloca is bad?

[Andrew Cagney]

Christopher Faylor wrote:
> 
> A patch that I recently submitted to gdb-patches used the alloca ()
> function to allocate memory.  I've been told in private email that I
> mustn't use alloca because "stack corruption problems are harder to
> debug" than heap corruption problems.

The principal reason is that it is non-portable. Some hosts have fairly
arbitrary limits on how much can be alloca()'d.  A black/white please
don't use this is easier to follow than some vague ``only when''
guideline .... Yes, multi-arch has put us into the grey.

Other secondary factors in the decision would have included the
observation that alloca (and stack arrays) (well actually just C :-) can
lead to nasy buffer overflow bugs that corrupt the stack.

	Andrew


> I was surprised by this assertion and so I thought I'd ask for a
> consensus here.  Should the use of alloca be deprecated in gdb?
> 
> It is my assertion that the amount of bookkeeping and overhead required
> to use malloc in a way that is analogous with alloca essentially
> nullifies the "harder to debug" argument.  malloc requires a free and
> many times, in gdb context, the only way to guarantee a free is with the
> use of the cleanup function.  Any time you add the complexity of
> something like 'cleanup()' (or whatever other mechanism you use to
> ensure that what you malloc is automatically freed) you can't claim to
> have reduced debugging problems.  Speaking of free, with alloca you
> don't have memory leaks.  With malloc, you do.
> 
> If alloca is bad, then why are local arrays and pointers to local
> variables and parameters ok?
> 
> Inquiring minds...
> 
> cgf