[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4fa46ccb-2f3f-4524-b81e-677bd67cff72@gmail.com>
Date: Sat, 1 Nov 2025 16:50:28 -0400
From: Demi Marie Obenour <demiobenour@...il.com>
To: musl@...ts.openwall.com, Laurent Bercot <ska-dietlibc@...rnet.org>
Cc: libc-alpha@...rceware.org, 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
On 11/1/25 15:27, Laurent Bercot wrote:
>> 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.
C++ depends on C for allocation, and the same problem could also happen
in C. It's just more common in C++.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 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.
