[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <em9c9fe887-9e9a-4172-a556-3daef74647b5@0d85dd4c.com>
Date: Sat, 01 Nov 2025 22:12: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>
Subject: Re[2]: Re: realloci(): A realloc() variant that works in-place
>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.
Indeed. The proposed modified realloci, however, always reserving the
maximum available space in the block if the user requested something
larger than is available, sounds like it would be suboptimal because
chances are the user will need a relocation anyway.
>struct my_data_structure {
> struct list_head list; // The embedded list node
> int value;
> char name[]; // C99 Flexible Array Member
>};
So... a linked list, living in the heap with one malloc per node, of a
structure containing a FAM. Yeah, in this case I can understand why
you'd need realloci. But honestly, if you know you will need to increase
the length of the name array, this is a pretty poor choice of data
structure, painting yourself into a corner. In this case, I would
certainly make name a char * field, which would be the only part that
needs to be reallocated, and the list pointers would never need
modification.
If you want to argue that the double indirection is costly in terms of
malloc, I agree; and since struct my_data_structure now has a fixed
size,
it is easy to implement the linked list differently, e.g. as an array
(potentially dynamically-sized, but reallocs here would be occasional
and relocation of the list would not be an issue), using indices instead
of pointers, which cuts down the amount of heap manipulation compared to
one-malloc-per-node way more than using a FAM would.
My point is that relocation issues are _a solved problem_ in C already.
If a realloci function appears, I will never use it, because realloc()
covers all my use cases; and never should any C application developer.
My concern is that it would be a footgun, encouraging bad design
practices, and C is not in shortage of that.
--
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.
