Request for feedback on WG14 proposal N3849 (alloc_at_least)

[Wilco Dijkstra]

Hi,

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

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

All it does is avoid a call to realloc when it fits in the allocated size.
However realloc already does this optimization, so I don't see how it helps.
Requesting N bytes but wanting to use N+1 is not worthwhile - if it's better
to use a larger block, why not allocate the larger block in the first place?

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

Or huge allocations that use mmap, but again realloc handles that too.

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

In GLIBC there are at most 15 extra bytes for standard chunks, so on average
you might get an extra 7.5 bytes...

I don't see this being worth the extra complexity in allocators and applications.
You still have to call realloc if you want to resize further, so it's better to ensure
realloc is well optimized.

Cheers,
Wilco