Re: proper realloc(p,0) behavior?

[Bruno Haible]

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>