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

[Reid Kleckner via lldb-commits]

rnk wrote:

I apologize I haven't carefully read @ojhunt 's self-admitted wall of text, but it seems to me like a possible next step would be to set up a call to come up with some acceptable compromise.

My high-level input is, I wonder if Oliver's concerns about `__wrap` can be fixed by using more precise math-y naming by invoking the word "modular", or "mod2". Yeah, I know, it's bikeshedding, but names are important, they are the essentially unskippable documentation. As a reader, this seems like the meaning of the examples you are passing back and forth would be clearer:

```
uint8_t __mod2 x = ...;
if (x + 1 == 0) { ... } // Is there a special case to narrow integer literals?
...
uint64_t u64 = 1ull<<32;
uint32_t __mod2 u32 = 1;
u64 = u64 + u32; // Do we widen u32, and then do a `+mod2` operation?
// Does the assignment from `uint64_t __mod2` allow implicit conversion?
```

If you think about the canonical use case for intentional unsigned integer overflow, it's probably cryptographic algorithms, where the algorithms are usually defined in terms of modular arithmetic. If we call it that, something math-y programmers will be less likely to reach for the feature when they are simply trying to implement an overflow check.

---

As for `__nowrap`, my imperfect understanding is that it basically constrains the implementation to either behave as `-fwrapv` or `-ftrapv`. It would be incorrect to apply LLVM `nsw` / `nuw` qualifiers to the resulting math instructions.

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