Re: memset (0, 0, 0);

[Richard Earnshaw <rearnsha@arm.com>]

> 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.