[musl] Re: realloci(): A realloc() variant that works in-place

[Alejandro Colomar]

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/>).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251109/b2e55344/attachment-0001.sig>