From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26574 invoked by alias); 20 Nov 2002 16:05:24 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 26538 invoked from network); 20 Nov 2002 16:05:20 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 20 Nov 2002 16:05:20 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 11ACD3E39; Wed, 20 Nov 2002 11:05:15 -0500 (EST) Message-ID: <3DDBB2BA.90601@redhat.com> Date: Wed, 20 Nov 2002 08:05:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Klee Dienes , Alan Modra Cc: binutils@sources.redhat.com, gdb@sources.redhat.com Subject: Re: [RFA] Replace strdup with xstrdup in tic30-dis.c References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00257.txt.bz2 > 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