![]() |
|
Message-ID: <PAWPR08MB8982B239BD6F9205E0F8C361837BA@PAWPR08MB8982.eurprd08.prod.outlook.com> Date: Wed, 25 Jun 2025 18:07:06 +0000 From: Wilco Dijkstra <Wilco.Dijkstra@....com> To: Alejandro Colomar <alx@...nel.org>, Eric Blake <eblake@...hat.com> CC: "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 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? Cheers, Wilco
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.