[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: 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?


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.


  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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]