[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <x5ptlbyizmmswdnwrraoq3zk5difkgkqmokgr5bq3mwxe6wpap@5tu3xr6pliat>
Date: Wed, 25 Jun 2025 13:10:52 -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:47:55PM +0200, Alejandro Colomar wrote:
> Hi Eric,
>
> On Wed, Jun 25, 2025 at 07:36:01PM +0200, Alejandro Colomar wrote:
> > 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.
>
> Oh, the text is still there; I didn't see it. :)
>
> The realloc function returns 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 think I'll just remove that parenthetical, since it serves little
> purpose.
On the contrary, I think the parenthetical has a great purpose - it is
a hint to implementors that preserving the pointer values between the
old and new object is a desirable (but not mandatory) characteristic.
Deleting the parenthetical might cause people to misinterpret the
standard by mixing up "new object" with "new pointer", at which point
they might try to "fix" realloc(p,s) to never return p but always copy
data. When doing valgrind or other similar malloc-checking analysis
of a program, I'd actually WANT that behavior for realloc, to make
sure my code is always safely dealing with any potential of a moved
pointer; but in the common case, I do NOT want the speed penalty of an
implementation that always has to copy memory rather than reusing
pointers just because the standard omitted the parenthetical hinting
that such behavior is permissible.
--
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.
