Re: when can realloc fail?

CBFalconer wrote:
Joe Wright wrote:
... snip ...
I have posed a question a little upthread: Given ptr points to an
area to be freed, and then 'realloc(ptr, 0);'. Granted that realloc
can return NULL or not, will the allocation of ptr be freed? I'd
like to think so.

You don't know, which is one more reason to consider such
allocaters to be brain-dead.

The question isn't so much about implementations, but
about what the Standard requires/allows. In the passage
you and pete pointed out, the Standard allows realloc(p,0)
to return NULL or non-NULL at the implementation's whim.
If it returns NULL, the programmer has no way to distinguish
failure from success. (The dodge of changing zero to one is
clever, but the cure is worse than the disease: You get a
reliable success/failure indication, but at the price of
either failing unnecessarily or creating a memory leak.)

It seems to me the Standard could have defined realloc(p,0)
as equivalent to (free(p), (void*)NULL), but neither C90 nor
C99 actually chose to do so. (C90 had the free() equivalence
but didn't specify the returned value; C99 describes the
returned value but removes the free() language.)

The Rationale claims that realloc(p,0) *does* free the
memory pointed to by p, basing the claim on the deallocation
of the old object. But since the NULL return is overloaded
to mean both "failure" and "success: nothing allocated," the
programmer is stuck with a diagnostic problem.

Suggested work-around: Don't call realloc() with the second
argument equal to zero. That is, call realloc() to grow a
memory area or to shrink it, but avoid shrinking it to nothing.
If you want to free memory, use free().

--
Eric Sosman
esosman@xxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: A solution for the allocation failures problem
    ... Can you find anything in the standard which *allows* this behaviour? ... it defines how your C program is supposed to behave. ... previously allocated memory available for further allocation. ... says the memory will be made available for further allocation. ...
    (comp.lang.c)
  • Re: Freeing memory - will it be available immediately
    ... Your interpretation of "as the standard defines it" is ... Your interpretation of "for further allocation" as "for futher ... Except that this ignores the very reason for the standard, ... return the memory back to the OS in the manner you describe. ...
    (comp.lang.c)
  • Re: malloc under linux
    ... It means what it says, i.e., even if malloc returns a non-null ... memory might not actually be allocated. ... Standard even when some other process is killed and sufficient memory is ... I can't see how the Standard does not permit lazy allocation, ...
    (comp.lang.c)
  • Re: Freeing memory - will it be available immediately
    ... Earlier you did seem to stress the fact that the standard does nothing ... further allocation" as returning the memory to the place it came from. ... word "allocate" can be taken to be a change of ownership. ...
    (comp.lang.c)
  • Re: calloc/free: a preplexing observation
    ... > that any program that writes to stdout can be strictly conforming): ... > whether lazy allocation is conforming or not, ... > The requirement for mallocis that it has to behave as the standard ... > recursive function call attempts to allocate a terabyte of memory, ...
    (comp.lang.c)