[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <vuk2dkkdfc7dknk3aahpzznqzdbqlpwkemcwfikxagtrdeydpl@fs6xgy2nar5b>
Date: Sun, 9 Nov 2025 19:16:48 +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
On Sun, Nov 09, 2025 at 06:38:30PM +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.
>
> 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);
> }
Self-correction:
void *my_realloc(void *p, size_t n);
[[gnu::malloc(my_realloc, 1)]] [[gnu::malloc(my_free)]]
void *my_realloc(void *p, size_t n);
(I need to repeat the prototype, to be able to refer to itself.)
>
> [[gnu::malloc(realloc, 1)]] [[gnu::malloc(free)]]
And these attributes should use my_realloc and my_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/>).
--
<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.
