[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3661104.0N7aAr316n@tjmaciei-mobl5>
Date: Sat, 01 Nov 2025 13:02:11 -0700
From: Thiago Macieira <thiago@...ieira.org>
To: musl@...ts.openwall.com, Laurent Bercot <ska-dietlibc@...rnet.org>
Cc: libc-alpha@...rceware.org, musl@...ts.openwall.com,
Arthur O'Dwyer <arthur.j.odwyer@...il.com>,
Jonathan Wakely <jwakely@...hat.com>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
On Saturday, 1 November 2025 12:27:00 Pacific Daylight Time 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.
What would this function return for an implementation that has a linear heap
and the present block is the last one? PTRDIFF_MAX?
In any case, the inability to use it in a multithreaded environment is a
showstopper.
> This sounds like it would not work with multithreading, but neither
> would your new realloci approach that returns a supposedly usable size.
realloci() would be usable in multithreaded environments because it can
perform a lock and be sure that the requested size did fit, or some other size
did, before unlocking and returning.
> 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.
Just because this discussion started from the C++ side does not mean it's only
usable from C++. Everything one can do in C++ one can do in C, even if it
takes writing a bit more code.
The godbolt example I posted:
https://godbolt.org/z/ET6M6hW6q
is effectively entirely C, except for the actual element in the vector (a
std::string), which I chose only to make it realistic, to show that a problem
exists today to be solved. But it can be any C struct whose pointer address
must remain stable, such as when it's inserted in a linked list. Think of for
example:
struct my_data_structure {
struct list_head list; // The embedded list node
int value;
char name[]; // C99 Flexible Array Member
};
Suppose I want to update the name stored in this element and the new name is
bigger than the current one. With realloci() we could query the allocator to
see if it can be extended without moving, which removes the need to update the
pointers to this element in the list. If this element is stored in a lock-free
list, updating the previous and next elements may be an expensive operation
we'd prefer to avoid.
Even if were only a C++ problem and thus not a Standard C or POSIX problem, it
would be a problem for the *C Library implementations* to resolve anyway. The
alternative would be that the C++ Standard Libraries deploy their own
replacements for malloc() & free() that could be extended in place,
duplicating implementations and thus adding more complexity to running
applications, and being unable to share heaps. As a I user, I would prefer not
to see that happen.
It would not be the first time the C library implementations need to solve C++
problems (think __cxa_thread_atexit()) and won't be the last. If the C
committee doesn't agree on the value, so be it. The work for the people in
this thread probably remains the same.
--
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.
