[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251110151135.GE1827@brightrain.aerifal.cx>
Date: Mon, 10 Nov 2025 10:11:35 -0500
From: Rich Felker <dalias@...c.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>,
Alejandro Colomar <alx@...nel.org>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
On Sun, Nov 09, 2025 at 06:47:54PM -0800, Paul Eggert wrote:
> On 2025-11-09 17:20, Rich Felker wrote:
> > The only way the lifetime of P does not end is if realloc returns a
> > null pointer indicating failure.
>
> Yes, and my point was that Alejandro's summary of the situation (which you
> went along with) got this detail wrong. And once one gets this detail right
> (which static analyzers of course can do), that discredits the idea that
> static analyzers are so dumb that they can't handle conditional results from
> functions like realloc. On the contrary, static analyzers do that sort of
> thing routinely, and they could continue to do so if the standard were
> changed slightly in the direction I proposed.
It's not a "conditional result" unless the condition you mean is
failure to allocate. realloc *always frees the old object* on success.
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.
