[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <p4gub25csid2mny5dsfrvtzs7nncer3ub6463yg7vhdmxjgqyw@w6kbogyq73vl>
Date: Wed, 25 Jun 2025 13:03:13 -0500
From: Eric Blake <eblake@...hat.com>
To: Alejandro Colomar <alx@...nel.org>
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 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).
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
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.
