Re: [RFA] Replace strdup with xstrdup in tic30-dis.c

[Klee Dienes <klee at apple dot com>]

Another option would be to add a xmalloc_set_failure_handler() to 
libiberty for use by GDB.

Regardless of what we plan to do though, I argue that replacing 
unchecked malloc() and strdup() calls in opcodes/ with xmalloc and 
xstrdup is a useful step forward.  The real bug in the code is the lack 
of checking the return value; using malloc instead of xmalloc is just 
sweeping the problem under the rug.  Using xmalloc may not be the final 
solution, but at least it prevents random unknown crashes, and marks 
the location of the bug for a later "go through and fix all the xmalloc 
calls" pass.

I'm not arguing against a "no xmalloc in new code" rule, just that an 
unchecked xmalloc is better than an unchecked malloc.

On Tuesday, November 19, 2002, at 05:09 PM, Andrew Cagney wrote:

> > On Tue, Nov 19, 2002 at 11:26:12AM -0500, Andrew Cagney wrote:
> > > I know BFD intentionally doesn't use the x*() functions.  Instead it 
> > > tries to clean up and return an error indication when there is a 
> > > malloc() failure.
> > > What of the disassembler though?  GDB, which is depending on the 
> > > disassembler, needs to be able to recover from low memory (aka 
> > > malloc() failure) conditions.
> > I OK'd the patch too quickly, then remembered the no xmalloc rule..
> > Then on grepping through opcodes/*, I saw so many xmalloc and xstrdup
> > calls that I hardly felt like correcting the patch.  We're no worse
> > off with an xstrdup call than an unchecked strdup call.  :-(
> Perhaphs the coding standard applies to just bfd?
>
> Assuming it does apply to opcodes/, remember, you've got to start 
> somewhere.  One good pace to start is to stop the addition of further 
> stray xmalloc() calls.
>
> Andrew