This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: alloca is bad?
- To: Christopher Faylor <cgf at redhat dot com>
- Subject: Re: alloca is bad?
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Fri, 10 Nov 2000 17:20:46 +1100
- Cc: gdb at sources dot redhat dot com
- References: <20001109212032.A26464@redhat.com>
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