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

[Andrew Cagney <ac131313@redhat.com>]

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

Just FYI, GDB is currently intercepting the calls by implementing its 
own xmalloc() and having them linked in before libiberty.  See utils.c.

> 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.

True.

Problem is, a malloc() -> xmalloc() transformation also sweeps the 
problem under the carpet.  The code no longer dumps core so it must be 
fixed, right?

Accepting a work around involves a trade off.  I think here, an implicit 
decision has already made: the disassembler shall use xmalloc(); the 
disassembler shall leak memory.

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

Which reminds me, how is the elimination of true/false from "bfd.h" going?

Andrew