From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Nick Duffek Cc: cagney@cygnus.com, gdb@sources.redhat.com Subject: Re: alloca is bad? Date: Sat, 11 Nov 2000 11:37:00 -0000 Message-id: <3A0D9FC7.48720E54@cygnus.com> References: <3A0CE1DB.6F6B1E93@cygnus.com> <200011111713.eABHDrN15135@rtl.cygnus.com> X-SW-Source: 2000-11/msg00096.html 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 To: Christopher Faylor Cc: Michael Meissner , gdb@sources.redhat.com, Andrew Cagney 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 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).