This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]