[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <y7lkac7rhgqscvlhs5dlhvqjvzm5poaj7quytsamugcyldis6b@2nvbi4v54u5f>
Date: Sun, 9 Nov 2025 18:38:25 +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 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.
Right now, I can do:
void
my_free(void *p)
{
return free(p);
}
[[gnu::malloc(free)]]
void *
my_realloc(void *p, size_t n)
{
return realloc(p, n);
}
[[gnu::malloc(realloc, 1)]] [[gnu::malloc(free)]]
void *
my_malloc(size_t n)
{
return malloc(n);
}
If realloc(3) wouldn't create a new lifetime, this use of attributes
wouldn't be legal, and so I couldn't tell the static analyzer how to
analyze this code. We'd need significantly more complex rules to
describe the relationship between these functions.
Or maybe this would still be valid... Since
[[gnu::malloc(deallocator)]] doesn't imply [[gnu::malloc]], then this
could still be valid.
But because old pointers would be conditionally be valid, it would be
more difficult to determine whether the pointer is free(3)d or not, as
the old pointers could be used for free(3)ing. So, V7 Unix semantics
could reduce the value of this attribute.
Have a lovely night!
Alex
> Static analyzers should be our servants, not our masters.
>
--
<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.
