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

[Alejandro Colomar]

Hi H. Peter,

On Fri, Jun 20, 2025 at 07:30:50PM -0700, H. Peter Anvin wrote:
> On 2025-06-20 18:21, Alejandro Colomar wrote:
> > 
> > On Fri, Jun 20, 2025 at 04:58:04PM -0700, H. Peter Anvin wrote:
> > > On 2025-06-17 04:52, Wilco Dijkstra wrote:
> > > > Hi Alejandro,
> > > > 
> > > > > > The purpose of realloc(p, 0) is to free memory.
> > > > > 
> > > > > No.  The purpose of realloc(p,0) is to resize a block to size 0.
> > > > 
> > > > That's arguing semantics. Whether you return the original block or a new
> > > > small block is an internal implementation detail. The goal is to free the memory.
> > > > 
> > > 
> > > There is actually a third option.
> > 
> > This isn't actually a third option.  This is the option I'm proposing.
> > :)
> > 
> 
> :)
> 
> > > 
> > > If a non-NULL pointer is returned, from either malloc or realloc, it needs
> > > to be unique, but there is no requirement that it needs to be *accessible.*
> > 
> > Nope, it doesn't need to be unique.  There's no requisite in the
> > standard that the result of malloc(0) is unique.
> > 
> 
> I think it is for C++, though.

Hmm, could be.  I was talking with Doug and we found it was removed in
C99 (the requirement was present in C89).  I'll ask why it was changed
some day, but I don't want to change the attention from realloc(3) from
now.

Once we merge this, I'll start asking about uniqueness.

Also, Doug told me he has a use case for unique pointers, so I might
write a paper for restoring that requirement, if we can.  But I'll do
that after we finish with this.


Have a lovely day!
Alex

> 
> 	-hpa
> 

-- 
<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/20250621/b2745045/attachment.sig>