[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proper realloc(p,0) behavior?
From: |
Eric Blake |
Subject: |
Re: proper realloc(p,0) behavior? |
Date: |
Fri, 25 Mar 2011 05:44:27 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.9 |
On 03/24/2011 05:52 PM, Bruno Haible wrote:
>
> Is a "pointer to an object of size 0" (in the C99 speak) necessarily a
> non-null pointer?
Yes.
In C99, malloc(0) has two behaviors, per 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."
A zero-size object is therefore necessarily a unique pointer to a
non-NULL location, where it is permissible to take the address 1 beyond
the end of the array but not dereference that address.
> 1) AIX malloc with malloc(0) => NULL would be non-compliant, and I've never
> heard anyone claim so. (We just _prefer_ the glibc behaviour where
> malloc(0) is normally non-NULL.)
AIX malloc(0) is C99 compliant - it takes option two of failing to
malloc a zero-sized object.
> 2) Calling memchr with a NULL pointer and 0 size argument would be
> invalid.
That has no bearing on this question - calling memchr with size 0 is
valid regardless of whether you pass the NULL pointer or any other
pointer, because you are not accessing the pointer.
> So, a pointer to an object of size 0 can also be null.
No, it can't.
> 1) realloc(p,0) with p != NULL can return NULL as a pointer to the
> new object, and
No, because returning NULL implies failure (as in the AIX case, where
you can't allocate a zero-sized object), so C99 requires p to be
untouched in that case.
> 2) you cannot infer from a NULL return value that "the new object could
> not be allocated".
According to C99, yes you can.
>
> These URLs and
> <https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=show_archive.tpl&source=L&listname=austin-group-l&id=15252>
> don't give any more details or rationale for their interpretation of C99.
The C99 folks pointed to N872 item 19c as their rationale for where they
intentionally changed the wording in C99 compared to what it had been in
C89 to require that realloc(p,0) returning NULL does not free p.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n872.htm states:
19c. realloc rewrite (Meyers)
The *realloc* function deallocates the old object pointed to
by *ptr* and returns a pointer to a new object that has the
size specified by *size*. The contents of the new object
shall be the same as the old object before deallocation up
to the lesser of the size of the old object and *size*. Any
bytes in the new object beyond the size of the old object
have indeterminate values.
If *ptr* is a null pointer, the *realloc* function behaves
like the *malloc* function for the specified size.
Otherwise, if *ptr* does not match a pointer earlier
returned by the *calloc*, *malloc*, or *realloc* function,
or if the space has been deallocated by a call to the *free*
or *realloc* function, the behavior is undefined. If memory
for the new object cannot be allocated, the old object is
not deallocated and its value is unchanged.
Returns
The *realloc* function returns a pointer to the new object,
which may have the same value as *ptr*, or a null pointer if
the new object could not be allocated.
--
Eric Blake address@hidden +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
- Re: proper realloc(p,0) behavior?, (continued)
- Re: proper realloc(p,0) behavior?, Paul Eggert, 2011/03/25
- Re: proper realloc(p,0) behavior?, Eric Blake, 2011/03/25
- [PATCH] xmalloc: revert yesterday's regression, Eric Blake, 2011/03/25
- Re: proper realloc(p,0) behavior?, Paul Eggert, 2011/03/25
- Re: proper realloc(p,0) behavior?, Eric Blake, 2011/03/25
[PATCH] realloc: document portability problem, Eric Blake, 2011/03/24
Re: proper realloc(p,0) behavior?, Bruno Haible, 2011/03/24
- Re: proper realloc(p,0) behavior?,
Eric Blake <=
- Re: proper realloc(p,0) behavior?, Bruno Haible, 2011/03/25
- Re: proper realloc(p,0) behavior?, Eric Blake, 2011/03/25
- Re: proper realloc(p,0) behavior?, Paul Eggert, 2011/03/25
- Re: proper realloc(p,0) behavior?, Eric Blake, 2011/03/25
Re: proper realloc(p,0) behavior?, Bruno Haible, 2011/03/24
Re: proper realloc(p,0) behavior?, Pádraig Brady, 2011/03/25