From: Kevin Buettner <kevinb@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH RFA] utils.c: Fix xcalloc (0, 0) behavior
Date: Mon, 05 Mar 2001 12:51:00 -0000 [thread overview]
Message-ID: <1010305205130.ZM5329@ocotillo.lan> (raw)
In-Reply-To: <3AA3F64E.9F0302A5@cygnus.com>
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
next prev parent reply other threads:[~2001-03-05 12:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1010303075808.ZM24102@ocotillo.lan>
2001-03-03 0:02 ` Kevin Buettner
2001-03-05 12:28 ` Andrew Cagney
2001-03-05 12:39 ` J.T. Conklin
2001-03-05 12:51 ` Kevin Buettner [this message]
2001-03-05 7:52 David Taylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1010305205130.ZM5329@ocotillo.lan \
--to=kevinb@cygnus.com \
--cc=ac131313@cygnus.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox