[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <96d1c4ca-d51a-6ec3-ae33-7856d0ca166b@redhat.com>
Date: Fri, 20 Jun 2025 23:58:15 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...hat.com>
To: Alejandro Colomar <alx@...nel.org>
cc: 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>, Rich Felker <dalias@...c.org>,
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: alx-0029r1 - Restore the traditional realloc(3) specification
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!
Maciej
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.
