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

[Alejandro Colomar]

Hi Paul, Rich,

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.

I agree I was wrong in my wording.  And considering that
[[gnu::malloc(free)]] doesn't imply [[gnu::malloc]], then your proposed
semantics are also easy to express.  I guess this could do it:

	void *eggert_realloc(void *, size_t);
	[[gnu::malloc(eggert_realloc, 1)]] [[gnu::malloc(free)]]
	void *eggert_realloc(void *, size_t);

	void *current_realloc(void *, size_t);
	[[gnu::malloc(current_realloc, 1)]] [[gnu::malloc(free)]]
	[[gnu::malloc]]
	void *current_realloc(void *, size_t);

And since analyzers already need to consider when it fails, I guess
you're right that adding p==q to the logic of the analyzer wouldn't hurt
so much.


Have a lovely day!
Alex

-- 
<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/20251110/5933ab72/attachment.sig>