[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250625202710.GQ1827@brightrain.aerifal.cx>
Date: Wed, 25 Jun 2025 16:27:10 -0400
From: Rich Felker <dalias@...c.org>
To: Wilco Dijkstra <Wilco.Dijkstra@....com>
Cc: Alejandro Colomar <alx@...nel.org>, Eric Blake <eblake@...hat.com>,
"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>,
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: 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.
No, it should not. I've addressed this at least two times already in
this thread.
> So I'm wondering whether we should more clearly specify this - whenever
> it's possible to not fail, don't return NULL?
No, it should fail if it cannot meaningfully perform the operation.
The application is always free to keep using the old object if it was
larger than needed, but this way, the application *knows it still has
that memory tied up* rather than being lied to that it was freed, and
can make an informed decision about what to do. Usually the right
thing is to back out the operation it was performing, because
something along the way was tying up an inordinate amount of memory.
Continuing with forward progress unaware of this condition is much
more likely to lead to a state where it can't back out and recover.
Rich
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.
