From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3271 invoked by alias); 20 Nov 2002 02:05:18 -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 3159 invoked from network); 20 Nov 2002 02:05:16 -0000 Received: from unknown (HELO dc-mx02.cluster1.charter.net) (209.225.8.12) by sources.redhat.com with SMTP; 20 Nov 2002 02:05:16 -0000 Received: from [66.189.46.2] (HELO platinum.local.) by dc-mx02.cluster1.charter.net (CommuniGate Pro SMTP 3.5.9) with ESMTP id 7415806; Tue, 19 Nov 2002 20:39:43 -0500 Date: Tue, 19 Nov 2002 18:05:00 -0000 Subject: Re: [RFA] Replace strdup with xstrdup in tic30-dis.c Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: Alan Modra , binutils@sources.redhat.com, gdb@sources.redhat.com To: Andrew Cagney From: Klee Dienes In-Reply-To: <3DDAB683.6010005@redhat.com> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00240.txt.bz2 Another option would be to add a xmalloc_set_failure_handler() to libiberty for use by GDB. 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. I'm not arguing against a "no xmalloc in new code" rule, just that an unchecked xmalloc is better than an unchecked malloc. On Tuesday, November 19, 2002, at 05:09 PM, Andrew Cagney wrote: >> 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. :-( > > Perhaphs the coding standard applies to just bfd? > > Assuming it does apply to opcodes/, remember, you've got to start > somewhere. One good pace to start is to stop the addition of further > stray xmalloc() calls. > > Andrew > >