Hi Siddhesh, Thank you for your comments and suggestions!
On Fri, Nov 7, 2025 at 5:19 PM Siddhesh Poyarekar <[email protected]> wrote: > > 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. We've ended up sending the `malloc_span` changeset and skipping the `alloc_size`-side changes for now. The __counted_by__ suggestion sounds totally reasonable to me; I'll keep it in mind if/once we have to get back to it. For the record, here is the new PR: https://github.com/llvm/llvm-project/pull/167010 -- Aleksandr > > Thanks, > Sid
