[clang] [Clang] Introduce malloc_span attribute (PR #167010)

Erich Keane via cfe-commits cfe-commits at lists.llvm.org
Thu Nov 13 07:49:52 PST 2025


================
@@ -5247,6 +5247,21 @@ yet implemented in clang.
   }];
 }
 
+def MallocSpanDocs : Documentation {
+  let Category = DocCatFunction;
+  let Heading = "malloc_span";
+  let Content = [{
+The ``malloc_span`` attribute can be used to mark that a function which acts
+like a system memory allocation function and returns a span-like structure,
+where the returned memory range does not alias storage from any other object
+accessible to the caller.
+
+In this context, a span-like structure is assumed to have two fields, one of
+which is a pointer to the allocated memory and another one is an integer type
----------------
erichkeane wrote:

> With that in mind, I think we can start off strict and relax later without breaking code. e.g., maybe we start with supporting `int` through `long long` (and unsigned varieties) but not `_BitInt` initially, along with any non-smart pointer type. And later we relax to allow other things, and users can use one of the `__has_attribute` feature test macros to test for differences.

I hadn't thought of the start/end pointers, I think we should probably make sure that works, that is really sensible.  

As far as the integer types:  `isIntegerType` includes `_BitInt` and enums, which I think we can all admit are WRONG.  So theres at least tests that need to be written.

The more I think about it, the more I can make `int`and bigger builtin-ints ONLY make sense.  So:
```
if (const auto *BT = dyn_cast<BuiltinType>(CanonicalType))
     BT->isInteger(); // plus some tests for size
```

would be reasonable.

I think the smart-pointer thing is a bridge too far, and I'm definitely OK rejecting those, at least short term.  `malloc` implies that these are pretty darn C-esque, so smart-pointers seem like a massive extension that won't get used.


SO I guess the fallout for me is:

pointer + integer/integer + pointer/ pointer + pointer // All need testing and should be supported.

AND, if it is an integer, `getTypeSize(Context.IntTy) >= getTypeSize(int-type)` would be accpetable to me.

https://github.com/llvm/llvm-project/pull/167010


More information about the cfe-commits mailing list