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