[musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

[Vincent Lefevre]

On 2025-06-20 13:58:23 +0200, Alejandro Colomar wrote:
> On Fri, Jun 20, 2025 at 04:11:23AM +0200, Vincent Lefevre wrote:
> > You should also consider the end of 7.20.3p1 (which applies to calloc,
> > malloc and realloc):
> > 
> >   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.
> 
> Right.  I missed that part.
> 
> So, C99 and C11 allow realloc(p,0) to return a null pointer.
> 
> > Consider the case "a null pointer is returned" with realloc(non_null,0).
> > I can see 2 possible interpretations:
> > 
> > 1. This is always a failure (corresponding to "a null pointer if the
> > new object could not be allocated" in 7.20.3.4p4). But I doubt that
> > this is the intended behavior, as there would be major memory leaks
> > in practice with such an implementation and would make such a call
> > useless.
> > 
> > 2. This means that the memory is entirely freed, which is a success.
> > This makes your assumption "paragraph 4 rules out the possibility of
> > returning a null pointer on success" above wrong. However, in order
> > to know whether a null pointer means a success (memory entirely freed)
> > or a failure (for the case "the behavior is as if the size were some
> > nonzero value"), the application would need to know which kind of
> > implementation it is (e.g. guessed by tools like configure tests).
> 
> To disambiguate, we need to read
> 
> <https://port70.net/~nsz/c/c99/n1256.html#7.20.3.4>
> 
> First p4:
> 
> 	4	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.
> 
> So, a null pointer, which is allowed for r(p,0), means that "the new
> object could not be allocated".
> 
> And then we read the last sentence of p3:
> 
> 	3	[...]
> 		If memory for the new object cannot be allocated,
> 		the old object is not deallocated and its value is unchanged.
> 
> So, the input pointer must not be freed.

Yes, this is what I mentioned in interpretation 1 above (so with
memory leaks in practice, as applications call realloc(non_null,0)
to free memory, while memory will never be freed).

But I believe that this was not the intent of the C Committee.
If it were, the text would have been different, IMHO.

This is too late for a defect report anyway, as the current standard
is C23 and realloc(non_null,0) is now UB. But if one wants to avoid
the UB in a future standard, the above remarks need to be considered.

> I'd say glibc is non-conforming, even if this could possibly have been
> unintended by the C Committee.

Well, strictly speaking, with the UB, it is conforming (at least with
a non-null pointer). I'm not sure that speaking of conformity against
old standards makes sense if there is a suspicion of defect (and in
particular, if this has been resolved by a change in the current
standard, like here).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)