[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proper realloc(p,0) behavior?
From: |
Bruno Haible |
Subject: |
Re: proper realloc(p,0) behavior? |
Date: |
Fri, 25 Mar 2011 00:52:00 +0100 |
User-agent: |
KMail/1.9.9 |
Eric Blake wrote:
> C99 requires realloc(p,0) to either successfully allocate a 0-sized
> array (just like malloc(0)) or to return NULL and leave p unchanged.
>
> glibc treats realloc(p,0) like free(p) (as permitted by C89), and using
> C99 compliant code would thus result in a double-free bug.
I'm not following this interpretation of ISO C99 that you and Martin Sebor
are proposing. In my opinion, C99 explicitly allows that
realloc(p,0) does a { free(p); return 0; }
Here's the C99 text (both from the IS9899-1999.pdf file and from the
current update <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf>):
=============================================================================
* malloc:
Description
The malloc function allocates space for an object whose size is specified
by size and whose value is indeterminate.
Returns
The malloc function returns either a null pointer or a pointer to the
allocated space.
* realloc:
Description
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 that of the old object
prior to deallocation, up to the lesser of the new and old sizes. 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 a pointer to the old object), or a null pointer if the
new object could not be allocated.
=============================================================================
Is a "pointer to an object of size 0" (in the C99 speak) necessarily a
non-null pointer? There are some people who claim so, but I don't.
Otherwise
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.)
2) Calling memchr with a NULL pointer and 0 size argument would be
invalid.
So, a pointer to an object of size 0 can also be null. Then - read the
above description -
1) realloc(p,0) with p != NULL can return NULL as a pointer to the
new object, and
2) you cannot infer from a NULL return value that "the new object could
not be allocated".
So, the glibc, AIX, HP-UX, OSF/1, Solaris behaviour of implementing
realloc(p,0) as
{ free(p); return 0; }
is actually C99 compliant. And it was introduced precisely for C99 and
POSIX compatibility:
<http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=7c2b945e1fd64e0a5a4dbd6ae6592a7314dcd4b5>
So, yes I do believe C99 is ambiguous here, and as a consequence programmers
don't know what to do if they call realloc(p,0) and it returns NULL.
> POSIX 2008 is ambiguous - it states that it defers to C99 requirements,
> but then has the wording of the C89 implementation that permits glibc
> behavior. The proper resolution for POSIX is currently under debate:
> http://austingroupbugs.net/view.php?id=400
>
> Uli refuses to fix glibc (but somehow I'm not surprised):
> http://sourceware.org/bugzilla/show_bug.cgi?id=12547
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.
Bruno
--
In memoriam Óscar Romero <http://en.wikipedia.org/wiki/Óscar_Romero>
- Re: proper realloc(p,0) behavior?, (continued)
- Re: proper realloc(p,0) behavior?, Paolo Bonzini, 2011/03/25
- Re: proper realloc(p,0) behavior?, Eric Blake, 2011/03/25
- Re: proper realloc(p,0) behavior?, Paolo Bonzini, 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
- [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 <=
- Re: proper realloc(p,0) behavior?, Eric Blake, 2011/03/25
- 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