From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3881 invoked by alias); 19 Nov 2002 21:42:49 -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 3873 invoked from network); 19 Nov 2002 21:42:46 -0000 Received: from unknown (HELO mta01bw.bigpond.com) (139.134.6.78) by sources.redhat.com with SMTP; 19 Nov 2002 21:42:46 -0000 Received: from bubble.local ([144.135.24.78]) by mta01bw.bigpond.com (Netscape Messaging Server 4.15 mta01bw Jul 16 2002 22:47:55) with SMTP id H5UEX300.1ZJ for ; Wed, 20 Nov 2002 07:41:27 +1000 Received: from CPE-144-136-184-243.sa.bigpond.net.au ([144.136.184.243]) by bwmam04.mailsvc.email.bigpond.com(MailRouter V3.2 35/312688); 20 Nov 2002 07:41:51 Received: (qmail 19734 invoked by uid 179); 19 Nov 2002 21:41:26 -0000 Date: Tue, 19 Nov 2002 13:42:00 -0000 From: Alan Modra To: Andrew Cagney Cc: Klee Dienes , binutils@sources.redhat.com, gdb@sources.redhat.com Subject: Re: [RFA] Replace strdup with xstrdup in tic30-dis.c Message-ID: <20021119214126.GP997@bubble.sa.bigpond.net.au> Mail-Followup-To: Andrew Cagney , Klee Dienes , binutils@sources.redhat.com, gdb@sources.redhat.com References: <555D137A-FB43-11D6-84AF-00039396EEB8@apple.com> <20021119071305.GM997@bubble.sa.bigpond.net.au> <3DDA6624.5000500@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DDA6624.5000500@redhat.com> User-Agent: Mutt/1.4i X-SW-Source: 2002-11/txt/msg00233.txt.bz2 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. :-( -- Alan Modra IBM OzLabs - Linux Technology Centre