Permitting malloc/alloc_size attributes for span-returning allocation functions

[Siddhesh Poyarekar]

On 2025-11-05 14:30, Aleksandr Nogikh via Gcc wrote:
> Hello GCC Maintainers,
> 
> We are currently discussing a proposal for Clang (under review here:
> https://github.com/llvm/llvm-project/pull/165433) to relax the
> constraints on the malloc and alloc_size attributes.
> 
> The proposal is to permit these attributes not just on
> pointer-returning functions, but also on allocation functions
> returning span-like structs (for custom allocators, but also for
> functions like "size returning new" mentioned in wg21.link/P0901R11).
> 
> In this context, a "span-like" struct is one that contains a pointer
> and the size of the pointed-to object, such as std::span or
> sized_allocation_t from P0901R11. Our proposed heuristic in Clang
> defines this as a struct with exactly two members: a pointer type as
> the first field and an integer type as the second.

On the alloc_size front, this sounds like a job for __counted_by__, 
since it is now extended to apply to pointers, i.e. there shouldn't be a 
need for a new attribute there.

> For now, we intend to only relax the constraints on the allowable
> functions for malloc and alloc_size with no code-generation impact. In
> the future, we would like to leverage these attributes to improve code
> optimization, such as by using the implied absence of aliasing of
> pointers returned inside the freshly allocated span-like structs.
> 
> The motivation for the changes is as follows: While P0901R11 was
> proposed as a performance improvement to communicate the actual number
> of bytes allocated from the allocator, the design of memory-safe
> interfaces also benefits from returning span-like objects from
> allocator functions if the requested bytes do not always match the
> returned bytes. Allowing these attributes on functions not just
> returning pointers would be beneficial for improving code generation
> and enabling static analysis that requires knowledge of heap
> allocation sites. We believe relaxing this constraint is the right way
> forward.
> 
> However, only changing it on the Clang side raises concerns about the
> compatibility of the semantics of these attributes between Clang and
> GCC. We would appreciate your brief feedback on whether this is a
> direction GCC would also consider or if you have an alternative
> position on this.

I like the current consensus in the PR, i.e. make a new malloc_span 
attribute for a malloc-like annotation of span-returning functions.  The 
alloc_size aspect (and the heuristic to validate the struct that is 
returned) should be based on the pointer member of the struct being 
decorated with a __counted_by__, pointing to the size element in the 
same struct.  That way the struct could be arbitrarily structured aside 
from those two relevant members, which should give future flexibility.

Thanks,
Sid