Request for feedback on WG14 proposal N3849 (alloc_at_least)

[Charles Munger]

Thank you for your reponse!

On Thu, Apr 23, 2026 at 4:20 AM Florian Weimer <fweimer@redhat.com> wrote:

> * Charles Munger:
>
> > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3849.pdf
> >
> > I have a proposal for the next C standard to add a new allocator API,
> > and I'd like to solicit feedback from glibc's developers to ensure
> > it's not going to cause you problems.
>
> The free_sized description is not self-contained, so it's hard to tell
> if it's appropriate.
>
> The free_aligned_sized function might not be needed if the caller of
> free_sized would have to specify the exact size returned from
> aligned_alloc_at_least.
>
free_sized and free_aligned_sized were added in C23; this change includes
the description of how they interact with the new allocation functions. The
rationale behind the changes is documented further down in the (admittedly
long) paper; basically if you allocate an array of some sized type, you
might store that size in terms of the number of elements rather than the
number of bytes, and so if the allocator returned a size that wasn't a
multiple, you would not have the precise size to pass back.

>
> These new functions are not very meaningful with glibc malloc, except
> maybe the initial switch from the small string optimization in
> std::string to the heap-allocated size, where they could make the full
> 40 bytes available instead of the requested 31 (with the libstdc++
> implementation), avoiding a future resize.  Using those extra characters
> might avoid further resizing in some cases.
>
For what it's worth, I think you can already do that with the
https://en.cppreference.com/cpp/memory/allocator_traits/allocate_at_least
API; this new proposal I think would only offer new functionality to C
programs.

>
> Another potential useful secnario would be aligned_alloc_at_least with a
> large alignment, where the tail could be made available for use, but
> that seems much less common.
>
> In other cases, it's just about making available very few extra bytes
> per allocation.  This is not likely to change as glibc malloc evolves.
>
Won't glibc return a larger block from the freelist or a size bucket match
if it's available?

>
> Thanks,
> Florian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260423/29e990e4/attachment.htm>