From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16401 invoked by alias); 20 Nov 2002 23:09:02 -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 16359 invoked from network); 20 Nov 2002 23:09:01 -0000 Received: from unknown (HELO mta01ps.bigpond.com) (144.135.25.133) by sources.redhat.com with SMTP; 20 Nov 2002 23:09:01 -0000 Received: from bubble.local ([144.135.25.87]) by mta01ps.bigpond.com (Netscape Messaging Server 4.15 mta01ps Jul 16 2002 22:47:55) with SMTP id H5WDMZ00.0W4 for ; Thu, 21 Nov 2002 09:08:59 +1000 Received: from CPE-144-136-184-243.sa.bigpond.net.au ([144.136.184.243]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.2 125/920983); 21 Nov 2002 09:08:54 Received: (qmail 23889 invoked by uid 179); 20 Nov 2002 23:08:47 -0000 Date: Wed, 20 Nov 2002 15:09:00 -0000 From: Alan Modra To: Andrew Cagney Cc: binutils@sources.redhat.com, gdb@sources.redhat.com Subject: Re: [RFA] Replace strdup with xstrdup in tic30-dis.c Message-ID: <20021120230847.GI997@bubble.sa.bigpond.net.au> Mail-Followup-To: Andrew Cagney , binutils@sources.redhat.com, gdb@sources.redhat.com References: <3DDBB2BA.90601@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DDBB2BA.90601@redhat.com> User-Agent: Mutt/1.4i X-SW-Source: 2002-11/txt/msg00298.txt.bz2 On Wed, Nov 20, 2002 at 11:05:14AM -0500, Andrew Cagney wrote: > 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? Bombing with "out of memory" is nearly as bad. > 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. The disassembler doesn't need to leak memory. Hmm, I suppose it could be difficult to free things that aren't exposed to the interface. You'd rather bfd_alloc, which is freed automagically on bfd_close, eh? > >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? Has that become my job?? ;) -- Alan Modra IBM OzLabs - Linux Technology Centre