[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251109181140.GC1827@brightrain.aerifal.cx>
Date: Sun, 9 Nov 2025 13:11:40 -0500
From: Rich Felker <dalias@...c.org>
To: Alejandro Colomar <alx@...nel.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
On Sun, Nov 09, 2025 at 06:38:25PM +0100, Alejandro Colomar wrote:
> Hi Paul,
>
> On Sun, Nov 09, 2025 at 07:31:37AM -0800, Paul Eggert wrote:
> > On 2025-11-09 03:37, Alejandro Colomar wrote:
> > > > > 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.
> >
> > Again, this is backwards. If the spec for P=realloc(Q,R) is changed so that
> > it's valid to check P==Q afterwards (which it is on every practical
> > production platform), then static analyzers can and should be changed
> > accordingly. The P==Q situation will not count as a memory leak, and other
> > situations will still count. This will be an improvement over the current
> > situation, where static analyzers issue false alarms about such code.
>
> My point was that it's easier to consider the lifetime of P ends at
> every realloc(3) call than to consider it to end only if Q!=P.
I agree with this. Moreover, checking if P!=Q *should* remain
undefined. Anything you can do with the result is wrong.
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.
