[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250621024442.GJ1827@brightrain.aerifal.cx>
Date: Fri, 20 Jun 2025 22:44:42 -0400
From: Rich Felker <dalias@...c.org>
To: "Maciej W. Rozycki" <macro@...hat.com>
Cc: Alejandro Colomar <alx@...nel.org>, libc-alpha@...rceware.org,
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>,
Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>,
Joseph Myers <josmyers@...hat.com>,
Florian Weimer <fweimer@...hat.com>,
Andreas Schwab <schwab@...e.de>, Thorsten Glaser <tg@...bsd.de>,
Eric Blake <eblake@...hat.com>,
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>,
Martin Uecker <ma.uecker@...il.com>,
Christopher Bazley <chris.bazley.wg14@...il.com>,
eskil@...ession.se
Subject: Re: Re: alx-0029r1 - Restore the traditional realloc(3)
specification
On Fri, Jun 20, 2025 at 11:58:15PM +0100, Maciej W. Rozycki wrote:
> Hi Alejandro,
>
> > After the useful discussion with Eric and Paul, I've rewritten a draft
> > of a proposal I had for realloc(3) for C2y. Here it is (see below).
>
> I've been following all the previous discussion (despite not having been
> explicitly cc'd) and I'm yet going to read through and chew over your
> proposal, but not before next week as it's quite late into this one here
> already. A thought has struck me however, at the high level.
>
> Given all the (understandable) fuss and the lack of symmetry (at least in
> some implementation variants) between `malloc(0)' and `realloc(p, 0)', and
> last but not least conflicting desires, both of which having their pros
> and cons, how about we actually fulfil the desires of both camps and come
> up with a set of entirely new APIs, say (1) `mallocn'/`reallocn' and (2)
> `mallocz'/`reallocz', that for zero-sized allocation requests consistently
> respectively:
>
> (1) return NULL, in the case of `reallocn' having freed any previous
> allocation,
>
> (2) return a pointer to a valid allocation, forbidden to access and the
> size of which might be zero, in the case of `reallocz' having freed or
> possibly shrunk any previous allocation?
>
> Implementations could then provide either semantics with their legacy
> `malloc'/`realloc' APIs, possibly following your proposal, mostly for
> software that does not ever care about zero-sized allocations, which I
> think is quite substantial a subset.
>
> It seems to me that the overhead for such separate APIs wouldn't be that
> high, and where suitable they could even be exported from system headers
> as macros or static always inline functions wrapping around the one core
> implementation of each, so as to let the compiler optimise away the
> uninterested case with many calls to these APIs where the compiler can
> statically prove size to be zero or nonzero.
>
> Thank you for your perseverance with this matter anyway, and have a good
> weekend!
I really don't think anyone wants this. Nobody wants the bad behavior
with regard to returing null. Neither applications nor implementors.
All that some implementors (understandably) want is to avoid making
changes. The above-proposed change just makes *everyone* unhappy and
makes the situation much more confusing and worse.
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.
