Request for feedback on WG14 proposal N3849 (alloc_at_least)

[Florian Weimer]

* Charles Munger:

> 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.

Applications could store the capacity in terms of the allocation size
instead of the element count.

>> 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.

If I understand the libstdc++ maintainers correctly, they cannot use
anything that's not part of the system malloc implemenetation becaus

> Won't glibc return a larger block from the freelist or a size bucket
> match if it's available?

We can split chunks and use the remaining part for something else.  I
think this is how glibc malloc differs from most other implementations,
which is why we keep this behavior.

Thanks,
Florian