Making it undefined at least allows you to trap it.
If you want wrap around, be explicit about it.
Conversation
Signed Integer Overflow is caught by UBSan and that is actually valuable. Unsigned just fails quietly 😞
1
3
This Tweet was deleted by the Tweet author. Learn more
This Tweet was deleted by the Tweet author. Learn more
You can use
__attribute__((no_sanitize("integer")))
To suppress it, so I would just turn it on and suppress it if needed and the suppression acts as self documentation but you should commmet why it is intended too.
stackoverflow.com/q/33351891/170
1
2
4
Can also suppress it on a case-by-case basis with __builtin_add_overflow, etc. and simply ignoring the result if it's meant to wrap around. Those intrinsics provide well-defined signed overflow if needed too, as long as you don't care about portability beyond Clang and GCC.
1
4
I prefer to mark it with the overflow intrinsics because it's more self-documenting. Can wrap them into functions defining wrapping operations instead of having the verbosity of the return value and output parameter and then use those in hash functions, etc. as needed.
1
3
Google has to work around a large number of non-bugs to keep expanding -fsanitize=integer coverage, and they've often marked non-trivial functions as no_sanitize which isn't great b/c it reduces coverage for other ops too and it's hard to tell which operations are meant to wrap.
1
2
Signed overflow remains undefined with no_sanitize too. It's not possible to mix -fwrapv with this, although I think it should be. Passing -fsanitize=signed-integer-overflow -fsanitize-trap=signed-integer-overflow -fwrapv doesn't catch any signed overflows due to weird UBSan UX.
1
2
It makes sense that -fwrapv removes signed overflow checks from -fsanitize=undefined, but it really shouldn't when passing -fsanitize=integer or -fsanitize=signed-integer-overflow. It's super weird that -fsanitize=integer -fwrapv will catch unsigned but not signed overflows...