[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2gxa6ci2z23jd6wfgxs4keg3uvagwwbyfwrpu67mffrsmazrsh@hjttc6hq5yky>
Date: Sun, 9 Nov 2025 12:37:01 +0100
From: Alejandro Colomar <alx@...nel.org>
To: Paul Eggert <eggert@...ucla.edu>
Cc: libc-alpha@...rceware.org, musl@...ts.openwall.com,
"A. Wilcox" <AWilcox@...cox-tech.com>, Lénárd Szolnoki <cpp@...ardszolnoki.com>,
Collin Funk <collin.funk1@...il.com>, Arthur O'Dwyer <arthur.j.odwyer@...il.com>,
Jonathan Wakely <jwakely@...hat.com>, "Paul E. McKenney" <paulmck@...nel.org>,
Thiago Macieira <thiago@...ieira.org>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
Hi Paul,
On Fri, Oct 31, 2025 at 02:33:22PM -0600, Paul Eggert wrote:
> On 10/31/25 14:13, Alejandro Colomar wrote:
>
> > Consider that realloci() would be significantly cheaper than realloc(3),
>
> Not in the case where the object doesn't move: they should be about the same
> speed. And when the object grows so much that it does need to move, the V7
> realloc approach should be a bit faster because you need to make just one
> call into the memory subsystem, not three (realloci + malloc + free).
>
> > That would make sanitizers and static analyzers unable to verify lots of
> > code
> No, just the opposite. Currently sanitizers etc. spend useless work checking
> for C23 rules that don't correspond to any hardware or correctness needs;
> they're simply rules imposed by the C committee. This checking is
> counterproductive to real-world software development.
I'm worried that it might decrease the ability of static analyzers to
detect memory leaks. Currently, a static analyzer (such as GCC's
-fanalyzer) can see calls to [[gnu::malloc(realloc, 1)]] functions and
assume that realloc(3) free's them. If realloc(3) would only free(3)
conditionally, then you couldn't apply that attribute, which would make
analysis more difficult.
Have a lovely day!
Alex
> If we fixed the realloc spec to better match how actual production hardware
> behaves, we could fix sanitizers to spend their time flagging real bugs
> instead of wasting their time (and developers' time) generating false
> alarms.
>
> > I wouldn't categorize it as hard to explain:
> Oh, it's not hard to specify a realloci API, or to implement it. What's hard
> is explaining its motivation: why it's needed and what it's good for. It's
> motivated by specialized applications that most programmers don't know about
> and don't need to. And these specialized applications would be better served
> by a 7th Edition Unix realloc.
--
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).
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.
