[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <em4a35ca7b-1891-41d4-acea-b05d7d942035@e6a2d9ee.com>
Date: Sat, 01 Nov 2025 19:27:00 +0000
From: "Laurent Bercot" <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Cc: libc-alpha@...rceware.org, musl@...ts.openwall.com, "Arthur O'Dwyer"
<arthur.j.odwyer@...il.com>, "Jonathan Wakely" <jwakely@...hat.com>, "Thiago
Macieira" <thiago@...ieira.org>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
>Where realloci() allocates at least 'size' bytes (but possibly more),
>and returns the actual usable size of the block.
If you're set on doing something like this, it would be simpler to
provide a function that just returns the usable size of the block,
under which realloc() is guaranteed not to relocate the object, and
above which it is guaranteed to relocate.
This sounds like it would not work with multithreading, but neither
would your new realloci approach that returns a supposedly usable size.
All in all I don't see why C should be polluted with functions that
are unusable by C programmers just to help optimize C++ implementations.
This sounds like a bad trade-off, and I feel like a C++-specific issue
should be solved in a C++-specific way.
--
Laurent
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.
