From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-13338-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 7115 invoked by alias); 8 Apr 2003 13:26:18 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 7074 invoked from network); 8 Apr 2003 13:26:16 -0000
Received: from unknown (HELO crack.them.org) (65.125.64.184)
  by sources.redhat.com with SMTP; 8 Apr 2003 13:26:16 -0000
Received: from nevyn.them.org ([66.93.61.169] ident=mail)
	by crack.them.org with asmtp (Exim 3.12 #1 (Debian))
	id 192t71-0007XI-00; Tue, 08 Apr 2003 08:26:07 -0500
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
	id 192t6t-0006Hm-00; Tue, 08 Apr 2003 09:25:59 -0400
Date: Tue, 08 Apr 2003 13:26:00 -0000
From: Daniel Jacobowitz <drow@mvista.com>
To: Richard.Earnshaw@arm.com
Cc: "Thomas,Stephen" <stephen.thomas@superh.com>,
	Geoff Keating <geoffk@geoffk.org>, gdb@sources.redhat.com,
	newlib@sources.redhat.com, bug-glibc@gnu.org,
	"McGoogan, Sean" <sean.mcgoogan@superh.com>,
	Andrew Cagney <ac131313@redhat.com>
Subject: Re: memset (0, 0, 0);
Message-ID: <20030408132559.GA24135@nevyn.them.org>
Mail-Followup-To: Richard.Earnshaw@arm.com,
	"Thomas,Stephen" <stephen.thomas@superh.com>,
	Geoff Keating <geoffk@geoffk.org>, gdb@sources.redhat.com,
	newlib@sources.redhat.com, bug-glibc@gnu.org,
	"McGoogan, Sean" <sean.mcgoogan@superh.com>,
	Andrew Cagney <ac131313@redhat.com>
References: <9FF3133289A7A84E81E2ED8F5E56B379604386@sh-uk-ex01.uk.w2k.superh.com> <200304080929.h389TuE03840@pc960.cambridge.arm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200304080929.h389TuE03840@pc960.cambridge.arm.com>
User-Agent: Mutt/1.5.1i
X-SW-Source: 2003-04/txt/msg00070.txt.bz2

On Tue, Apr 08, 2003 at 10:29:55AM +0100, Richard Earnshaw wrote:
> > 
> > Hi Geoff,
> > 
> > Which xmalloc are you referring to? The xmalloc in this case is a gdb internal function, defined in gdb/utils.c:
> > 
> > PTR xmalloc (size_t size)
> > {
> >   return xmmalloc (NULL, size);
> > }
> > 
> > And xmmalloc is:
> > 
> > void * xmmalloc (void *md, size_t size)
> > {
> >   void *val;
> > 
> >   if (size == 0)
> >     {
> >       val = NULL;
> >     }
> >   else
> >     {
> >       val = mmalloc (md, size);
> >       if (val == NULL)
> > 	nomem (size);
> >     }
> >   return (val);
> > }
> > 
> > So size=0 does indeed return NULL. Also, I have single stepped this code to verify that this is actually what happens.
> 
> It looks as though that implementation of xmalloc doesn't match the 
> general specification of xmalloc, which is that xmalloc must *never* 
> return NULL (see libiberty/xmalloc.c for the specification).
> 
> I'm not sure why gdb is trying to provide its own implementation of these 
> functions and not use those in libiberty.  Andrew?

The ones in libiberty call exit; the ones in gdb call error() and
unwind cleanups.  GDB prefers not to abort when it runs out of memory,
esp. if it can just abort the current operation and reclaim memory.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer