[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cj56sk437mxke3v4dp57xzktdolsin7jcxqxv7cykqydf7tk2v@tpfzornfzjqr>
Date: Wed, 25 Jun 2025 20:10:18 +0200
From: Alejandro Colomar <alx@...nel.org>
To: Eric Blake <eblake@...hat.com>
Cc: libc-alpha@...rceware.org, Florian Weimer <fweimer@...hat.com>,
bug-gnulib@....org, musl@...ts.openwall.com,
наб <nabijaczleweli@...ijaczleweli.xyz>, Douglas McIlroy <douglas.mcilroy@...tmouth.edu>,
Paul Eggert <eggert@...ucla.edu>, Robert Seacord <rcseacord@...il.com>,
Elliott Hughes <enh@...gle.com>, Bruno Haible <bruno@...sp.org>,
JeanHeyd Meneide <phdofthehouse@...il.com>, Rich Felker <dalias@...c.org>,
Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>, Joseph Myers <josmyers@...hat.com>,
Laurent Bercot <ska-dietlibc@...rnet.org>, Andreas Schwab <schwab@...e.de>, Thorsten Glaser <tg@...bsd.de>,
Vincent Lefevre <vincent@...c17.net>, Mark Harris <mark.hsj@...il.com>,
Collin Funk <collin.funk1@...il.com>, Wilco Dijkstra <Wilco.Dijkstra@....com>,
DJ Delorie <dj@...hat.com>, Cristian Rodríguez <cristian@...riguez.im>,
Siddhesh Poyarekar <siddhesh@...plt.org>, Sam James <sam@...too.org>, Mark Wielaard <mark@...mp.org>,
"Maciej W. Rozycki" <macro@...hat.com>, Martin Uecker <ma.uecker@...il.com>,
Christopher Bazley <chris.bazley.wg14@...il.com>, eskil@...ession.se
Subject: Re: alx-0029r4 - Restore the traditional realloc(3) specification
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/>
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
