>"""
>The argument n must be equal to the first argument of the call to
>allocate() that originally produced p,
>or in the range [m, count] if p is obtained from a call to
>allocate_at_least(m) which returned {p, count}
>"""
>
>This "or" cause is concerning as you can give any value in that range
>and if value is critical then
>allocator needs to know what exactly was returned from `allocate_at_least`.
>Or does this assume "bucket" allocation where only approximated size
>is enough to recover proper value?

The intention of `allocate_at_least` is that allocators may allocate at a larger granularity than bytes (i.e. might allocate based on 64 byte chunks of memory or in the case of large allocations might allocate pages directly) and thus if a allocation doesn't fully use up the last granule the space at the end is just wasted and can't be reused for other allocations, and so the code that requested the allocation may as well be told that that space is there so they can make better use of it if they can.

In such situations the allocator already has to deal with the fact that the size of an allocation doesn't fill up an entire granule, and so (p + count) for normal allocations doesn't necessarily point to the end of allocated memory, just the end of the *requested* allocated memory (this is also a problem with the general topic of the thread - memory allocators for new[] may not store the size of the array but rather the size of the memory allocation, which can be different). Therefore the allocator already has to deal with rounding up the sizes of allocations that weren't allocated with `allocate_at_least`, and since it's all going through the same deallocation function that rounding has to happen regardless of the function you used to allocate the memory originally.

Obviously that doesn't work if the implementation of `allocate_at_least` does something stupid like deliberately allocate a random amount of extra memory rather than just telling the caller about any leftover space, or decides that it'll treat allocations of 6 bytes different than an allocation of 5 or 7 bytes but still round up 5 bytes to a 7 byte allocation, but both of those things are very dubious in the first place and like you point out is actively punished by the API, so realistically nobody's going to do them.


On 14 April 2026 15:24:13 BST, Marcin Jaczewski via Std-Discussion <std-discussion_at_[hidden]> wrote:
>wt., 14 kwi 2026 o 16:08 Jason McKesson via Std-Discussion
><std-discussion_at_[hidden]> napisał(a):
>>
>> On Tue, Apr 14, 2026 at 5:42 AM Marcin Jaczewski via Std-Discussion
>> <std-discussion_at_[hidden]> wrote:
>> >
>> > wt., 14 kwi 2026 o 11:04 Yongwei Wu <wuyongwei_at_[hidden]> napisał(a):
>> > >
>> > > I think it can work on pointers to (an array of) non-trivially-destructible objects. Maybe nobody finds a real usage scenario for this, thus no one has proposed it?
>> > >
>> >
>> > Real usage for me of this feature would be reduce size of
>> > `std::vector` as in this case you could avoid `capacity` duplication
>> > in vector.
>> > Of corse this will work only if allocator used `new[]` instead other
>> > manual handling, but even in this case allocator should perhaps know
>> > how big array is?
>>
>> But the allocator's allocation and deletion functions explicitly take
>> a size. So the allocator explicitly does not need to know the size;
>> you have to provide it. And some allocators flat-out *cannot* know the
>> size; they just don't track that because the caller is supposed to.
>
>Ok, I missed this part, but updating my knowledge from
>cppreference.com I notice this:
>
>"""
>The argument n must be equal to the first argument of the call to
>allocate() that originally produced p,
>or in the range [m, count] if p is obtained from a call to
>allocate_at_least(m) which returned {p, count}
>"""
>
>This "or" cause is concerning as you can give any value in that range
>and if value is critical then
>allocator needs to know what exactly was returned from `allocate_at_least`.
>Or does this assume "bucket" allocation where only approximated size
>is enough to recover proper value?
>
>--
>Std-Discussion mailing list
>Std-Discussion_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion