JustinStitt wrote:
I went ahead and changed over to an experimental cc1 flag in
[`3fcb27c`](https://github.com/llvm/llvm-project/pull/148914/commits/3fcb27cbfd420c3ea228518f142e6ea95e2f247d).
I think we have just a couple lingering design wrinkles to iron out:
1) Should we allow overloading (also concerns C `_Generic`) on OBTs or not?
Currently it is allowed, see `clang/test/Sema/attr-overflow-behavior.cpp:95`
and related tests.
2) How are we treating function boundaries? I know @rjmccall and @ojhunt have
feelings around this.
```c
void foo(__ob_trap signed char a) {
// ...
}
void bar() {
int toobig = 1337;
foo(toobig); // to trap or not to trap? That is the question.
// currently, this traps.
}
```
@rjmccall Later down the line I think we can introduce some function attribute
`__must_check_overflow` that would verify that all parts of the parameter are
1) OBT trap and 2) constant expr non-overflowing (was there a (3)?). This would
help us spot programming errors like:
```c
// this specifier might be giving a "fake" guarantee about this
// parameter's lineage down at the callsites. We need a
`__must_check_overflow` func. attr. later
void foo(__ob_trap signed char a) {
// ...
}
void bar(signed char y) {
signed char x = 67;
x *= y; // might overflow and accidentally fall within [-128,127]
foo(toobig); // therefore, no trap here. think about allocators!
}
```
3) Should we allow partial template specializations on obt specifiers? From our
most recent meeting I recall folks mentioning partial template specializations
like the following:
```c
template <typename T>
void foo(__ob_trap T A);
```
https://github.com/llvm/llvm-project/pull/148914
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
