|
|
Message-ID: <i4gvmi26j6vz5ci56cgqjq3qynpgkybxcoochp5q2qsiibo2x2@vervvj2437jp>
Date: Mon, 10 Nov 2025 16:18:14 +0100
From: Alejandro Colomar <alx@...nel.org>
To: Rich Felker <dalias@...c.org>
Cc: Paul Eggert <eggert@...ucla.edu>, 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 Rich,
On Mon, Nov 10, 2025 at 10:11:35AM -0500, Rich Felker wrote:
> 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.
AFAIU, he meant that, a failure to allocate.
Have a lovely day!
Alex
>
> Rich
--
<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.