Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <xwxfv6ciq2sokhlsyo2puxjijfieep76bqu2lt2ocnhuutnosb@h5k6fbpiayi5>
Date: Sun, 29 Jun 2025 18:35:13 +0200
From: Alejandro Colomar <alx@...nel.org>
To: "H. Peter Anvin" <hpa@...or.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>, Laurent Bercot <ska-dietlibc@...rnet.org>, 
	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>, 
	"Maciej W. Rozycki" <macro@...hat.com>, Martin Uecker <ma.uecker@...il.com>, 
	Christopher Bazley <chris.bazley.wg14@...il.com>, eskil@...ession.se, 
	Daniel Krügler <daniel.kruegler@...glemail.com>, Kees Cook <keescook@...omium.org>, 
	Valdis Klētnieks <valdis.kletnieks@...edu>
Subject: Re: alx-0029r6 - Restore the traditional realloc(3) specification

Hi H. Peter,

On Sun, Jun 29, 2025 at 09:25:13AM -0700, H. Peter Anvin wrote:
> On 2025-06-27 07:01, Alejandro Colomar wrote:
> > Hi!
> > 
> > Here's a new revision of the proposal, addressing some points raised by
> > Mark, plus clarifying that the paragraph about when size is zero refers
> > to the total size, as Florian was concerned that it might not be
> > symmetric.
> 
> I don't know if it would be useful, but proposing a new interface of the
> form:
> 
> 	reallocp(&ptr, size)
> 
> ... to separate the status return from the pointer might be a really good
> idea.  This would hopefully eliminate users doing the "obvious":
> 
> 	ptr = realloc(ptr, size)

This is resolved with the reallocf(3) wrapper that FreeBSD provides,
which I pretend to standardize *after* fixing realloc(3).  This is
provided in Linux (and other POSIX) systems by the libbsd library,
present in many distros.

reallocf(3) is a realloc(3) wrapper that unconditionally frees the
input pointer, even on error.  So, it is designed to be used exactly as

	p = reallocf(p, size);
	if (p == NULL)
		goto err;

As simple as it gets.

> Not that this resolves anything in the short or even medium term, but
> perhaps can help avoid problems in the more distant time frame.  It is also
> an interface which is mostly trivial to infill.

No, this would make static analysis a lot harder.  Currently, realloc(3)
is specified as ending the lifetime of the input object, and creating a
new one, and a static analyzer could easily understand that with
attributes like the existing [[gnu::malloc(free)]] --although for some
reason, there's no similar existing attribute for realloc(3)--.
However, if the new object is created in the parameter, you'll have a
very hard time tracking that.


Have a lovely day!
Alex

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

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

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.