[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250629170532.GY1827@brightrain.aerifal.cx>
Date: Sun, 29 Jun 2025 13:05:33 -0400
From: Rich Felker <dalias@...c.org>
To: "H. Peter Anvin" <hpa@...or.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>,
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: Re: alx-0029r6 - Restore the traditional realloc(3)
specification
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":
No, please no. These interfaces (generic void* allocators that take a
void** argument to store the result in) are an *extremely bad
antipattern* that produces undefined behavior. What you end up with
are things of the form:
T *p;
reallocp((void **)&p, size);
which is obviously UB to us, but not to your average C programmer.
They just think it's what you're supposed to do when the compiler
tells you there's a type mismatch.
The only well-defined way to use such an interface is hideously ugly,
and no one does it:
T *p;
void *tmp = p;
reallocp(&tmp, size);
if (success) p = tmp;
Please note that this issue is not theoretical. I've encountered it in
the wild with posix_memalign, cudamalloc(), libavcoded allocation
functions, etc. Often folks build machinery on top of these where it's
impossible to extricate the UB without major architectural changes to
the code. The "double-pointer allocate" idiom just needs to be burned
with fire.
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.
