[Lldb-commits] [clang] [lldb] [Clang] Introduce OverflowBehaviorType for fine-grained overflow control (PR #148914)

[Justin Stitt via lldb-commits]

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