This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: alloca is bad?
- To: Nick Duffek <nsd at redhat dot com>
- Subject: Re: alloca is bad?
- From: Fernando Nasser <fnasser at cygnus dot com>
- Date: Sat, 11 Nov 2000 19:36:39 +0000
- CC: cagney at cygnus dot com, gdb at sources dot redhat dot com
- Organization: Red Hat Canada Ltd. - Toronto
- References: <3A0CE1DB.6F6B1E93@cygnus.com> <200011111713.eABHDrN15135@rtl.cygnus.com>
Nick Duffek wrote:
>
> On 11-Nov-2000, Andrew Cagney wrote:
>
> >This brings up an additional, possibly relevent, point. Given the code:
>
> > int a[size];
>
> >vs
> > int *const a = alloca (size * sizeof (int));
> >or int *const a = (int *) alloca (size & sizeof (int));
>
> >(er and there is even one in the above and no it wasn't contrived!) the
> >latter definitely has more potential error points (both when being
> >written and being maintained). Coding pratices that minimize a
> >programmers error rate should be considered.
>
> That's one of the strongest arguments in favor of alloca over malloc. The
> programmer error potential in these two lines of code:
>
> int *const a = alloca (size * sizeof (int));
> int *const a = malloc (size * sizeof (int));
>
> is exactly the same, but adding free() in the malloc case adds much more
> potential for errors, as demonstrated by the popularity of tools for
> finding memory leaks. The malloc case gets even more error-prone where we
> need to check for non-local exits and add cleanup chains.
>
Meomory leak -> small problem, easy to identify the culprit.
Stack corruption -> big problem, difficult to know even where to start.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9