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

[Alejandro Colomar]

Hi Paul,

On Fri, Oct 31, 2025 at 02:33:22PM -0600, Paul Eggert wrote:
> On 10/31/25 14:13, Alejandro Colomar wrote:
> 
> > Consider that realloci() would be significantly cheaper than realloc(3),
> 
> Not in the case where the object doesn't move: they should be about the same
> speed. And when the object grows so much that it does need to move, the V7
> realloc approach should be a bit faster because you need to make just one
> call into the memory subsystem, not three (realloci + malloc + free).
> 
> > 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.


Have a lovely day!
Alex

> If we fixed the realloc spec to better match how actual production hardware
> behaves, we could fix sanitizers to spend their time flagging real bugs
> instead of wasting their time (and developers' time) generating false
> alarms.
> 
> > I wouldn't categorize it as hard to explain:
> Oh, it's not hard to specify a realloci API, or to implement it. What's hard
> is explaining its motivation: why it's needed and what it's good for. It's
> motivated by specialized applications that most programmers don't know about
> and don't need to. And these specialized applications would be better served
> by a 7th Edition Unix realloc.

-- 
<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/9cff3624/attachment.sig>