Re: alloca is bad?

[Fernando Nasser <fnasser@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
From fnasser@cygnus.com Sat Nov 11 11:52:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Christopher Faylor <cgf@redhat.com>
Cc: Michael Meissner <meissner@cygnus.com>, gdb@sources.redhat.com, Andrew Cagney <cagney@cygnus.com>
Subject: Re: alloca is bad?
Date: Sat, 11 Nov 2000 11:52:00 -0000
Message-id: <3A0DA348.6BDDAFD4@cygnus.com>
References: <20001109212032.A26464@redhat.com> <20001109213750.28987@cse.cygnus.com> <20001109222231.A26675@redhat.com>
X-SW-Source: 2000-11/msg00097.html
Content-length: 632

Someone said that heap corruption was harder to track than stack
corruption.

I couldn't disagree more.  Many (most?) of the times the function tries
to return and gets a buggy return address and frame pointer.
It then crashes and you have no idea where it happened.

The heap contents won't make it into your stack related registers,
so when something tries to use the data and crashes you still have a starting
point (it may be much latter, but at least you have somewhere to start.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From eliz@delorie.com Sat Nov 11 12:55:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: bstell@ix.netcom.com
Cc: bstell@netscape.com, gdb@sources.redhat.com
Subject: Re: Displaying Unicode
Date: Sat, 11 Nov 2000 12:55:00 -0000
Message-id: <200011112054.PAA00938@indy.delorie.com>
References: <3A0B4885.B2384AE7@netscape.com> <200011101039.FAA29785@indy.delorie.com> <3A0C2791.A33BE9AC@ix.netcom.com> <200011102009.PAA00126@indy.delorie.com> <3A0C8E19.A8A6D355@netscape.com> <200011110732.CAA00523@indy.delorie.com> <3A0D94F6.9FC95EE8@ix.netcom.com>
X-SW-Source: 2000-11/msg00098.html
Content-length: 751

> From: bstell@ix.netcom.com
> Date: Sat, 11 Nov 2000 10:50:30 -0800
> 
> Here is a UCS-2 display routine I use:
> ==============================================
> void
> dump_UCharString(const UChar *uChar_str)
> {
>   while (*uChar_str) {
>     if (*uChar_str < 0x7F) {
>       printf("%c", *uChar_str);
>     }
>     else {
>       printf("\\x%02x%02x ", (*uChar_str)>>8, (*uChar_str)&0xFF);
>     }
>     uChar_str++;
>   }
> }

If all you need is to display something like "U+1234" for a UTF-8
encoding, then it should be easy to make this happen, either in GDB or
by calling a function from your program.

I thought you wanted something much more sophisticated (since text
which looks like "U+1234 U+4321 U+5789" etc. is all not easy to read).