[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <vedrjtwcoksm32czvk3jr4f3emzds3zlp4hzzk64hwmxvouhy6@cjenkvq2sdml>
Date: Wed, 25 Jun 2025 13:20:19 -0500
From: Eric Blake <eblake@...hat.com>
To: Wilco Dijkstra <Wilco.Dijkstra@....com>
Cc: Alejandro Colomar <alx@...nel.org>,
"libc-alpha@...rceware.org" <libc-alpha@...rceware.org>, Florian Weimer <fweimer@...hat.com>,
"bug-gnulib@....org" <bug-gnulib@....org>, "musl@...ts.openwall.com" <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>, 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" <eskil@...ession.se>
Subject: Re: alx-0029r4 - Restore the traditional realloc(3) specification
On Wed, Jun 25, 2025 at 06:07:06PM +0000, Wilco Dijkstra wrote:
> Hi Alejandro,
>
> > > > > +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"?
>
> > 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
>
> In principle a realloc that shrinks a non-NULL block does never need to fail.
> If it can't shrink the current block (either because internal design means it
> can't make it any smaller or because it doesn't have memory for a new
> smaller block) then it should preferably return the original pointer instead
> of returning NULL and taking the failure path.
>
> So I'm wondering whether we should more clearly specify this - whenever
> it's possible to not fail, don't return NULL?
Rich already made the strong argument that for an implementation that
encodes which arena a pointer was allocated from, shrinking in place
only works so long as the unused tail of the allocation does not
exceed a certain bound; and Alejandro removed the quote from Doug
McIlroy from an earlier version of the draft precisely because we do
NOT want the standard to mandate the inability to fail on shrinking an
object, as that will harm quality-of-implementation.
--
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.
