Freeing memory for nested structures

[Hallvard B Furuseth]

I agree with Hallvard's reply to this, but would like to try expressing
this in a slightly different way: 7.20.3p1 does apply. It gives
implementations permission to unconditionally fail to realloc to 0 bytes.

I think that means you don't agree
7.20.3p1's NULL is success return, while 7.20.3.4's is failure return.
On success return, the old object it deallocated. On failure return it
is not. Which is why realloc(non-null, 0) isn't allowed both - we
couldn't tell success from failure.

In any case, what matters for programming is that it's safest and
simplest to avoid realloc(non-null, 0).

 

[Harald van Dijk]

I think that means you don't agree 7.20.3p1's NULL is success return,
while 7.20.3.4's is failure return.

In that case, I agree that we disagree, though the issue of disagreement
was not stated in your other message, which I continue to agree with.
7.20.3p1's null pointer is a return value. It doesn't specify whether it
is a successful return or an indication of an error.

On success return, the old object
it deallocated. On failure return it is not. Which is why
realloc(non-null, 0) isn't allowed both - we couldn't tell success from
failure.

Right. 7.20.3p1 says realloc(non-null, 0) is allowed to always return a
null pointer. When realloc(non-null, 0) returns a null pointer, the old
object is not freed. I don't see how these are incompatible. It seems to
me to say that realloc(non-null, 0) is allowed to always ignore the
request and return a null pointer (without freeing anything).

In any case, what matters for programming is that it's safest and
simplest to avoid realloc(non-null, 0).

Definitely. If you want free, it has its own name. If you don't want free,
it doesn't usually make sense to pass a size of zero.