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

[Justin Stitt via lldb-commits]

JustinStitt wrote:

> Either always returning false (wrapping to uint8_t), or trapping in the overflow (?) check due to early narrowing, or returning false incorrectly but only if obt is enabled, and if obt is not enabled the only overflow exists on the promoted, but that can be prevented with:
> 
> ```c++
> uint8_t __obt_trap_wrapper u;
> if (__UINT32_T_MAX__ - u < some_other_value)
>   return;
> if (u + some_other_value > 0xff) {
> 
> }
> ```
> 
> But now even that overflow test is incorrect, no matter how or when the truncation happens: the overflow test now traps in some cases and produces incorrect false results in others.

@ojhunt For what it's worth, check out https://github.com/llvm/llvm-project/pull/100272 and https://github.com/llvm/llvm-project/pull/104889 and https://github.com/llvm/llvm-project/pull/105709 (all related to Overflow Pattern Exclusions) `-fsanitize-undefined-ignore-overflow-pattern=`. In some instances, we can tinker with instrumentation for common overflow idioms, even trumping OBT annotations.

Anyways, it is clear we cannot move forward with any of the current non-traditional narrowing rules. The question is where do we go from here? @rjmccall suggested [some models](https://discourse.llvm.org/t/rfc-v2-clang-introduce-overflowbehaviortypes-for-wrapping-and-non-wrapping-arithmetic/86507/42?u=justinstitt) in the RFC recently and @ojhunt has suggested more traditional and more strict options as well. My estimate from reading everyone's feedback is that there are maybe 3 or 4 different approaches. 

Of the approaches, most suggest that OBTs should behave more like regular arithmetic. Certain models mentioned by @kees and @ojhunt introduce strict typing -- involving manual casts to strip or add behavior; a rust-style approach. Everything must be the same bitwidth, signed ness and OBT kind. This particular strictness seems hard to adopt in the Linux kernel but removes 99% of mathematical ambiguity. Other models (like [wraps attribute feature](https://github.com/llvm/llvm-project/pull/86618) I tried to land 1.5 years ago) involve persisting OBT kind through the usual arithmetic conversions and using them to trap on truncation.

>From what I've read, most agree that `wrap` and `trap` should have the same semantics regardless of specific arithmetic model. However, I think there is some merit in considering different behaviors between `wrap` and `trap`. We could enforce a strict model, similar to what I mentioned above, for `trap` types and a more relaxed model for `wrap` types. I am also not opposed to some `__ob_strict_trap` or something like that, this allows for easier adoption from mature codebases.

We should schedule a meeting, when does the Clang Area Team meet next? Can we hijack part of that meeting? @AaronBallman 

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