BUG: realloc(p,0) should be consistent with malloc(0)

Alejandro Colomar alx@kernel.org
Thu Jun 19 10:09:37 GMT 2025


Hi Florian,

On Thu, Jun 19, 2025 at 11:20:51AM +0200, Florian Weimer wrote:
> * Alejandro Colomar:
> 
> > And yes, it means that realloc(p,0) can result in returning NULL without
> > setting errno, and thus passing the input pointer to free(3).  However,
> > the only situation in which this can happen is if p is a null pointer
> > itself.  This is explicitly said in the RETURN VALUE section, which is
> > normative.
> >
> > RETURN VALUE
> >
> > 	If size is 0,
> > 	...
> > 	either:
> >
> > 	    -  A null pointer shall be returned and,
> > 	       if ptr is not a null pointer, errno shall be set to EINVAL.
> >
> > 	    -  A pointer to the allocated space shall be returned, ...
> >
> > You're acting as if you didn't read that normative section, which is
> > very explicit in what can happen.
> 
> The part you elided, it also says this:
> 
> | Upon successful completion, realloc() and reallocarray() shall return
> | a pointer to the new object (which can have the same value as a
> | pointer to the old object), or a null pointer if the new object has
> | not been allocated.
> 
> I don't see anything clearing stating that the “has not been allocated”
> case is restricted to error scenarios only.

You're trying to interpret some wording that does not clearly specify in
either direction.  The paragraph I quoted is very explicit, and does not
leave room to interpretation.  It doesn't contradict what you quoted,
but rather clarify it.


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250619/a6d827c7/attachment.sig>


More information about the Libc-alpha mailing list