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

[Oliver Hunt via cfe-commits]

ojhunt wrote:

> @JustinStitt were looking over things, and I stumbled over something here...
> 
> > Thanks. So IIUC, the rule is:
> > 
> > 1. If the type of either operand of an arithmetic operator is `__ob_trap`,  the operator traps on overflow, and the result type is `__ob_trap`.
> 
> This is correct and what I was expecting.
> 
> > 2. If either the operand type or the destination type of an integer conversion is `__ob_trap`, the conversion traps on overflow.
> 
> This one, however, I think it not what we want, but I may be missing something.
> 
> ```
> int __ob_trap src = bigger_than_255;
> ...
> char dest = src;
> ```
> 

I don't think that's correct, it's equivalent to saying

```
int64 __ob_trap src = bigger_than_2_to_32;
...
int dest = src;
```

Should not trap, and similarly

```
void f(int);
int64 __ob_trap src = bigger_than_2_to_32;
f(src);
```

Would also not trap.

It also raises questions about what happens with

```
int __ob_wrap src = bigger_than_2_to_32;
...
char dest = src;
```

If ob_trap is ignored, ob_wrap should similarly be ignored, and thus we have UB overflow again.

> I don't think we want a trap on the `dest` assignment, since it isn't `__ob_trap`. It doesn't care about the truncation. This is a "sided" operation, unlike the arithmetic.

I disagree - the type has stated "overflow must have defined behavior', and in this case that behavior is to trap. This change implicitly subsumes that behavior, silencing the overflow trap, and rendering the overflow UB once more. Code of the form

```
type value = some_obt_qualified_value
```
Is not saying "overflow of `some_obt_qualified_value` does not matter", it is saying "overflow from operations on `value` does not matter".

>From a consistency point of view it also means that

```
narrower_type narrower = 0;
wider_type __ob_trap wider = wider_type(numeric_limits<narrower_type>::max()) + 1;
while (..) narrower += wider;
```

Will no longer have defined overflow behavior, and in the trapping configuration will not trap on the overflow.

For the char case specifically, no overflow will ever trap as arithmetic on any type narrower than int is promoted to int so

```cpp
char __obt_* src = ...;
char dst = src + 257; /* no overflow on the arithmetic, so we end up with an `int __obt` -> char that has ignored/UB overflow */
```

> This is in preparation for looking at having instrumentation added for explicit casts, like:
> 
> ```
> int b = bigger_than_255;
> ...
> int c = (u8 __ob_trap)b; // this should trap
> ```

I'm not sure what you're saying here - this works as specified currently and it does not require implicit casts to be treated differently?


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