[musl] Re: realloci(): A realloc() variant that works in-place

[Alejandro Colomar]

Hi James,

On Thu, Nov 06, 2025 at 01:03:52PM -0500, James Y Knight wrote:
> On Tue, Nov 4, 2025 at 7:38 PM Demi Marie Obenour <demiobenour@gmail.com> wrote:
> >
> > Would it be better to provide an allocation API that returns the amount
> > of memory actually allocated?  That would at least allow any padding at
> > the end of the allocation to be used instead of being wasted.
> 
> Yes, a new malloc variant with direct size feedback would be a much
> better idea than a new non-moving realloc variant. And, for people who
> care about usefulness for C++: that's already the direction C++
> started to go.

I disagree.  Most users don't need this, and should use this.

malloc(3) is already a special case of realloc(3), but it's useful
enough that it warrants a separate function.

However, for the case of realloci(), I don't see the usefulness of a
hypothetical malloci() to be enough to justify it.

After all, you can do this:

	p = malloc(size);
	if (p == NULL)
		goto fail;

	actual_size = realloci(p, size);

And the realloci() call should be cheap compared to malloc(3).  There's
absolutely no need to conflate this into a new function.  realloci()
should be enough.

If you'll do that often enough, feel free to wrap it yourself:

	void *
	malloci(size_t *size)
	{
		ssize_t  s;
		void     *p;

		p = malloc(*size);
		if (p == NULL)
			return NULL;

		s = realloci(*size);
		if (s != -1)
			*size = s;

		return p;
	}

But, there's no need to rush the growth.  It should be fine to wait
until you need to grow and then call realloci().

> Crucially, the new function must return both the pointer and the
> newly-allocated-size (which must be at least the requested size but
> could be more). Because this is a new API, it is explicitly opt-in for
> callers who know they _want_ to be able to grow into the remainder of
> an implementations rounded-up allocation-bucket size, and therefore
> would not trigger UB concerns or reduce the ability to detect
> overflows from "normal" fixed-size allocations done with malloc.
> 
> This has been covered before in C++ standards proposals:
> https://wg21.link/p0401 is already in C++23. It adds an API
> `std::allocation_result<T*, std::size_t> allocate_at_least(std::size_t
> n);" to the allocator template interface. libcxx defines this, and its
> standard-library containers e.g. vector call it.
> 
> Unfortunately, the default allocate_at_least currently only ever
> returns the exact requested-size, because there's currently no
> standard allocation API to request size-feedback from the default
> system allocator. But, if you provide a user-defined allocator
> template argument to the container (e.g. via "std::vector<int,
> MyCustomAllocator>"), you can use this functionality today.
> 
> To address the desire to have it by default, there is a second
> proposal: https://wg21.link/p0901, which proposes to add a new
> "operator new" overload (again, takes a requested size, returns
> pointer and actually-allocated size), that the default
> "allocate_at_least" should call. Unfortunately, that is NOT in C++
> yet. (I believe the last action was that there was mostly support for
> the feature but the proposal needed some tweaks).
> 
> It would be useful to have a C API for this if P0901 ends up in the
> C++ spec, because the default C++ standard library "operator new"
> implementations typically just call libc malloc.

I don't see this being used in C, so I think the C implementation should
be just enough to allow C++ to do their thing.  For that, realloci()
would be enough.  C++ can call it immediately after malloc(3) if needed,
and can wrap it with the malloci() from above if they want.


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251106/64fa0f3b/attachment.sig>