musl - Re: alx-0029r1 - Restore the traditional realloc(3) specification

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <xdt4l76ircncs6kh5ikhdsn5hsmh3wwceecl2pzg6zmqr7i2sm@slquforl5gfu>
Date: Sat, 21 Jun 2025 04:07:54 +0200
From: Alejandro Colomar <alx@...nel.org>
To: "Maciej W. Rozycki" <macro@...hat.com>
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 Maciej,

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,

I honestly still don't see the point in the camp returning NULL.  The
only reason it hasn't died, I think, is because of fear of breaking
existing code, but I don't see anyone asking for that behavior.

> 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?

I don't think (1) is useful.  But if anyone thinks so for their code,
I suggest they write an obvious inline wrapper for themselves.  But such
a wrapper should not be provided in the standard library, as it is
error-prone.

> 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.

Code using realloc(3) would continue having hidden bugs.  Part of my
goal is being able to use realloc(3) in the future without all these
issues, but another goal is fixing many existing bugs that no-one even
realized their code has.

I'm pretty sure you lift a rock and find three bugs in a call to
realloc(3).

>  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!

Thanks!


Have a lovely weekend!
Alex

> 
>   Maciej
> 

-- 
<https://www.alejandro-colomar.es/>

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.