[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 19:14:15 +0100
User-agent: KMail/1.9.9

Hi Eric,

Your reading of C99 is still not convincing.

About the question whether a "pointer to an object of size 0" is necessarily

On one hand, you refer to
which refers to, which says:

  "objects are composed of contiguous sequences of one or more bytes"

On the other hand:

> 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.

The description of memchr is:
  "The memchr function locates the first occurrence of c (converted to
   an unsigned char) in the initial n characters (each interpreted as
   unsigned char) of the object pointed to by s."

If you say that here the NULL pointer is a valid pointer to an "object"
of n characters, then a NULL pointer is also a valid return value of
malloc(0) and realloc(p,0), because that return value is specified
to be a "pointer to a new object that has the size" 0.

About the question whether realloc(p,0) may normally { free(p); return 0; }:

On one hand you say things that support my opinion that glibc's behaviour for
realloc(p,0) is C99 compliant:

> 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."
> ...
> AIX malloc(0) is C99 compliant - it takes option two of failing to
> malloc a zero-sized object.

This paragraph applies to malloc, realloc, and calloc. If it implies
that AIX malloc(0) is C99 compliant, then it also implies that it allows
realloc(p,0) to return NULL in the normal case.

On the other hand, you say things which I don't see backed by C99:

> 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.

You are trying to invoke 6.5.6.(8), which say that it is allowed to
compute r + 1 where r is the pointer to "the last element of an array object".
But the array we are talking of here has size 0, hence has no last element.

Or you are trying to infer the meaning of "pointer to object" from the text
in section 7.20.3. This is futile, because 7.20.3 is in the "Library" section
and does not define terms like "pointer to object".

In memoriam Franz Oppenhoff <http://en.wikipedia.org/wiki/Franz_Oppenhoff>

reply via email to

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