[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3660957.IU609i1g2E@tjmaciei-mobl5>
Date: Fri, 31 Oct 2025 14:14:48 -0700
From: Thiago Macieira <thiago@...ieira.org>
To: Alejandro Colomar <alx@...nel.org>, 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>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
On Friday, 31 October 2025 13:33:22 Pacific Daylight Time 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).
For data that can be moved in memory, I agree with you.
But that ignores the very common case of data not being allowed to move, which
precludes using realloc() in the first place, even if it would have kept the
pointers intact.
Movable (bitwise trivially relocatable) objects are the exception, not the
rule. I'd guesstimate that, in C++, for std::vector and similar classes, 99%
of the instatiations are done on non-relocatable types and 1% on relocatable
ones. It might be that this 1% of the case corresponds to 20% or even 50% of
all the memory allocations (by quantity or by data volume), but I'd be
surprised if it were larger than that.
The 1% may increase starting with C++29, as developers begin using the ability
to mark their types as bitwise trivially relocatable.
> > 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.
>
> 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.
The two are not mutually exclusive.
> > 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.
I'm telling you this would benefit 100% of C++ applications or a number so
close to it to be virtually indistinguishable. Most *developers* may never
notice they're using this, but they will still benefit from it, in their own
code via template instantiations and inlining.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Download attachment "signature.asc" of type "application/pgp-signature" (871 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.
