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. 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. Thanks, Aleksandr
