[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a8d2d588-bb4c-4404-8aa2-da968ef50d5e@cs.ucla.edu>
Date: Sun, 9 Nov 2025 18:47:54 -0800
From: Paul Eggert <eggert@...ucla.edu>
To: Rich Felker <dalias@...c.org>
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 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.
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.
