[clang] [Clang] Add wraps attribute (for granular integer overflow handling) (PR #86618)

Justin Stitt via cfe-commits cfe-commits at lists.llvm.org
Thu Apr 25 13:45:04 PDT 2024


JustinStitt wrote:

@efriedma-quic:
> This is declaring, then defining, a global variable; sorry if that wasn't clear.

Gotcha. 

> Probably should be an error? It'll be confusing no matter what we do.

I think it's OK for a global variable to be declared then later defined with additional attributes on it. There is some precedence with this (with deref and other type attributes):

```c
extern int* a;
int __attribute__((noderef)) *a = 0x0;
// no warnings/errors
```

This is really just letting the developer and compiler know that we shouldn't dereference `a` in this module. (same concept with `wraps`).
 
> I assume for your usage, you want the result of the arithmetic to be the same whether or not the compiler supports the "wraps" attribute, which constrains your choices.

Right, I'll make the necessary changes to allow for the attribute to persist through implicit integer promotions without changing arithmetic results.

> If you had a distinct canonical type, you would have had to make explicit decisions about a bunch of these things... and the rest would be stable independent of details of non-canonical type propagation.

Couldn't we say this about all the existing [Type Attributes](https://clang.llvm.org/docs/AttributeReference.html#type-attributes)? Should `noderef` have it's own type in clang? I think this would be a bit overkill. These attributes (and the proposed `wraps`) are just meant to give hints to developers and compilers. Specifically for wraps, the goal is to hint to readers of code that some arithmetic containing certain types or variables may wrap (and won't warn when doing so, so we can safely enable sanitizers).

I really don't see new types in the type system as being the most developer friendly option.



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


More information about the cfe-commits mailing list