alx-0029r4 - Restore the traditional realloc(3) specification

[Alejandro Colomar]

On Wed, Jun 25, 2025 at 01:03:13PM -0500, Eric Blake wrote:
> On Wed, Jun 25, 2025 at 07:35:58PM +0200, Alejandro Colomar wrote:
> > Hi Eric,
> > 
> > On Wed, Jun 25, 2025 at 03:16:06PM +0200, Alejandro Colomar wrote:
> > > > > 	@@ New footnote XXX
> > > > > 	+XXX)
> > > > > 	+While atypical,
> > > > > 	+<b>realloc</b> may fail
> > > > > 	+for a call that shrinks the block of memory.
> > > > 
> > > > Is it worth wording this as "may fail or return a different pointer
> > > > for a call that shrinks the block of memory"?
> > > 
> > > Yeah, we can add that.
> > 
> > I've changed my mind; the current wording of ISO C makes it that all
> > realloc(3) successful return values are new pointers, and it doesn't
> > seem to mention that the old pointer could be kept (I remember having
> > seen such text in older standards, I think; or maybe in POSIX), so let's
> > keep in that sense, and assume that realloc(3) always moves the memory,
> > even if sometimes it doesn't, as that is not observable by a conforming
> > program.
> 
> Quoting from n3299 (I'm not sure if that's the best draft of C23, or
> if I should attempt to get my hands on a more-precise pdf):
> 
> "The realloc function deallocates the old object pointed to by ptr and
> returns a pointer to a new object that has the size specified by
> size. The contents of the new object shall be the same as that of the
> old object prior to deallocation, up to the lesser of the new and old
> sizes. Any bytes in the new object beyond the size of the old object
> have unspecified values."
> 
> "The realloc function returns a pointer to the new object (which can
> have the same value as a pointer to the old object),..."
> 
> Return values are not "new pointers", but "new objects".  Your
> proposal is not changing the fact that all successful allocations are
> "new objects", and the standard is already clear that new objects can
> live in the same pointer.  But I still feel that it is worth the
> footnote to remind casual readers that even though reusing the pointer
> is permissible, it is not mandatory, and as a result, code that
> blindly assumes that shrinking an object will reuse the old pointer is
> broken.  (That change is independent of whether we fix realloc(p,0),
> but since we're in the area, we might as well make the standard easier
> to use).

Okay, sounds reasonable for just a few words; I'll add them.

Cheers,
Alex

> 
> By the way, even though the most common reason that the old and new
> pointer are the same is in order to avoid having to copy/move data
> from the old object to the new, there is another interesting case that
> the standard permits: an implementation that uses mmap() can have
> cases where the old pointer is different from the new pointer but
> where none of the object data had to be copied or moved, and that's
> because implementations can take advantage of MMU mapping metadata to
> direct the new pointer into resolving to the same underlying storage
> as the old pointer used to see.
> 
> -- 
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.
> Virtualization:  qemu.org | libguestfs.org
> 

-- 
<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/20250625/3d304d73/attachment.sig>