From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-13339-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 25140 invoked by alias); 8 Apr 2003 16:40:39 -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 25105 invoked from network); 8 Apr 2003 16:40:38 -0000
Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3)
  by sources.redhat.com with SMTP; 8 Apr 2003 16:40:38 -0000
Received: by fw-cam.cambridge.arm.com; id RAA05340; Tue, 8 Apr 2003 17:40:31 +0100 (BST)
Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5)
	id xma004937; Tue, 8 Apr 03 17:40:14 +0100
Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4])
	by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id OAA08819;
	Tue, 8 Apr 2003 14:45:11 +0100 (BST)
Received: from pc960.cambridge.arm.com (rearnsha@localhost)
	by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id h38DjBb05553;
	Tue, 8 Apr 2003 14:45:11 +0100
Message-Id: <200304081345.h38DjBb05553@pc960.cambridge.arm.com>
X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs
To: Daniel Jacobowitz <drow@mvista.com>
cc: 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>
Reply-To: Richard.Earnshaw@arm.com
Organization: ARM Ltd.
X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd)
X-Fax: +44 1223 400410
X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ.
Subject: Re: memset (0, 0, 0); 
In-reply-to: Your message of "Tue, 08 Apr 2003 09:25:59 EDT."
             <20030408132559.GA24135@nevyn.them.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 08 Apr 2003 16:40:00 -0000
From: Richard Earnshaw <rearnsha@arm.com>
X-SW-Source: 2003-04/txt/msg00071.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.
>

That's ok, but the bit about returning NULL isn't.  If we want a "malloc" 
routine that always returns NULL on zero size, we shouldn't call it 
xmalloc.

R.