Re: [PATCH RFA] utils.c: Fix xcalloc (0, 0) behavior

Re: [PATCH RFA] utils.c: Fix xcalloc (0, 0) behavior

[Kevin Buettner]

On Mar 3, 12:58am, Kevin Buettner wrote:

> Unfortunately, our implementation of xcalloc() and xmrealloc() choose
> to treat the NULL return value as an error condition and call nomem()
> as a result.

It just occurred to me that someone reviewing this patch may want
to know which xcalloc() call in gdb was responsible for generating
a zero-sized request.  See below for the backtrace...

Breakpoint 3, nomem (size=0) at /saguaro1/sourceware-ia64/src/gdb/utils.c:1005
1005      if (size > 0)
(top-gdb) bt 8
#0  nomem (size=0) at /saguaro1/sourceware-ia64/src/gdb/utils.c:1005
During symbol reading, type qualifier 'const' ignored.
#1  0x20000100f0162380 in xcalloc (number=0, size=8)
    at /saguaro1/sourceware-ia64/src/gdb/utils.c:1076
#2  0x20000100f00f6760 in alloc_gdbarch_data (gdbarch=0x10000024f18)
    at /saguaro1/sourceware-ia64/src/gdb/gdbarch.c:4229
#3  0x20000100f00eb8d0 in gdbarch_alloc (info=0x3fefffff3d7c0, 
    tdep=0x10000024eb0) at /saguaro1/sourceware-ia64/src/gdb/gdbarch.c:393
#4  0x20000100f01a4ee0 in ia64_gdbarch_init (info={
      bfd_architecture = bfd_arch_ia64, bfd_arch_info = 0x300341fb8, 
      byte_order = 1234, abfd = 0x0, tdep_info = 0x0}, arches=0x0)
    at /saguaro1/sourceware-ia64/src/gdb/ia64-tdep.c:1971
#5  0x20000100f00f7aa0 in gdbarch_update_p (info={
      bfd_architecture = bfd_arch_ia64, bfd_arch_info = 0x300341fb8, 
      byte_order = 1234, abfd = 0x0, tdep_info = 0x0})
    at /saguaro1/sourceware-ia64/src/gdb/gdbarch.c:4579
#6  0x20000100f00f90a0 in initialize_current_architecture ()
    at /saguaro1/sourceware-ia64/src/gdb/arch-utils.c:685
During symbol reading, type qualifier 'volatile' ignored.
#7  0x20000100f015b070 in gdb_init (
    argv0=0x3fefffffff880 "/home/kev/sourceware-ia64-bld/gdb/gdb")
    at /saguaro1/sourceware-ia64/src/gdb/top.c:685

Re: [PATCH RFA] utils.c: Fix xcalloc (0, 0) behavior

[Andrew Cagney]

Kevin Buettner wrote:
> 
> According to section 16.1 in Harbison & Steele, it is permissible for
> calloc(0,0) to return either NULL or an implementation defined unique
> pointer.  I've come across an implementation of calloc() which chooses
> to return NULL.

Does anyone know what the ISO-C standard has to say?  I think it would
be helpful if xcalloc() not only followed ISO-C but also did it in a
consistent way across platforms.

nice catch,

	Andrew

Re: [PATCH RFA] utils.c: Fix xcalloc (0, 0) behavior

[J.T. Conklin]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:

Andrew> Kevin Buettner wrote:
>> 
>> According to section 16.1 in Harbison & Steele, it is permissible for
>> calloc(0,0) to return either NULL or an implementation defined unique
>> pointer.  I've come across an implementation of calloc() which chooses
>> to return NULL.

Andrew> Does anyone know what the ISO-C standard has to say?  I think it would
Andrew> be helpful if xcalloc() not only followed ISO-C but also did it in a
Andrew> consistent way across platforms.

C9X, 7.20.3:

        If the size of the space requested is zero, the behavior is
        implementation-defined: either a null pointer is returned, or
        the behavior is as if the size were some nonzero value, except
        that the returned pointer shall not be used to access an
        object.

To make it consistant between implementations, we'd want to check for
zero size in xmalloc, xrealloc, and xcalloc() and return NULL before
the underlying functions are called.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: [PATCH RFA] utils.c: Fix xcalloc (0, 0) behavior

[Kevin Buettner]

On Mar 5,  3:25pm, Andrew Cagney wrote:

> Kevin Buettner wrote:
> > 
> > According to section 16.1 in Harbison & Steele, it is permissible for
> > calloc(0,0) to return either NULL or an implementation defined unique
> > pointer.  I've come across an implementation of calloc() which chooses
> > to return NULL.
> 
> Does anyone know what the ISO-C standard has to say?

The following is from the August 3, 1998 Committe Draft of WG14/N843...

    7.20.3 Memory management functions

    The order and contiguity of storage allocated by successive calls
    to the calloc, malloc, and realloc functions is unspecified.  The
    pointer returned if the allocation succeeds is suitably aligned so
    that it may be assigned to a pointer to any type of object and
    then used to access such an object or an array of such objects in
    the space allocated (until the space is explicitly freed or
    reallocated).  Each such allocation shall yield a pointer to an
    object disjoint from any other object.  The pointer returned
    points to the start (lowest byte address) of the allocated space. 
    If the space cannot be allocated, a null pointer is returned.  If
    the size of the space requested is zero, the behavior is
    implementation-defined:  either a null pointer is returned, or the
    behavior is as if the size were some nonzero value, except that
    the returned pointer shall not be used to access an object.  The
    value of a pointer that refers to freed space is indeterminate.

> I think it would be helpful if xcalloc() not only followed ISO-C but
> also did it in a consistent way across platforms.

In separate email to David Taylor and Peter Schauer, I suggested an
alternate implementation of xcalloc().  Peter was concerned that there
might be some breakage due to the fact that callers of xcalloc() (and
other memory allocation functions) presently expect to get back
non-NULL results.  I don't know if this is actually a problem or not,
but forcing NULL to be returned for zero-sized allocations on all
platforms would cause any problems to be found a lot sooner.

PTR
xcalloc (size_t number, size_t size)
{
  void *mem;
  
  if (number == 0 || size == 0)
    mem = NULL;
  else {
    mem = mcalloc (NULL, number, size);
    if (mem == NULL)
      nomem (number * size);
  }
  return mem;
}

I think this provides the desired consistency across platforms.  I'll
post a new patch shortly.

Kevin

Re: [PATCH RFA] utils.c: Fix xcalloc (0, 0) behavior

[David Taylor]

    Date: Sat, 3 Mar 2001 00:58:08 -0700
    From: Kevin Buettner <kevinb@cygnus.com>

    According to section 16.1 in Harbison & Steele, it is permissible for
    calloc(0,0) to return either NULL or an implementation defined unique
    pointer.  I've come across an implementation of calloc() which chooses
    to return NULL.

    Unfortunately, our implementation of xcalloc() and xmrealloc() choose
    to treat the NULL return value as an error condition and call nomem()
    as a result.

    The patch below corrects this oversight.

    Okay to apply?

	    * utils.c (xmrealloc): Don't call nomem() when return value
	    is NULL _and_ request size is 0.
	    (xcalloc): Likewise.

Yes.  Approved.

    Index: utils.c
    ===================================================================
    RCS file: /cvs/src/src/gdb/utils.c,v
    retrieving revision 1.31
    diff -u -p -r1.31 utils.c
    --- utils.c     2001/02/25 04:45:11     1.31
    +++ utils.c     2001/03/03 07:47:54
    @@ -1050,7 +1050,7 @@ xmrealloc (PTR md, PTR ptr, long size)
	 {
	   val = mmalloc (md, size);
	 }
    -  if (val == NULL)
    +  if (val == NULL && size != 0)
	 {
	   nomem (size);
	 }
    @@ -1072,7 +1072,7 @@ PTR
     xcalloc (size_t number, size_t size)
     {
       void *mem = mcalloc (NULL, number, size);
    -  if (mem == NULL)
    +  if (mem == NULL && number != 0 && size != 0)
	 nomem (number * size);
       return mem;
     }