Gah, I just managed to convince myself that unsigned integer wraparound being Defined Behavior is bad because it’s often a bug, but not caught by tools... what happened to me? I blame you 😂
Conversation
Making it undefined won't make it any better...
I was about to say that uint wraparound is useful, but then realized all the use-cases that come to my mind are from exploit development...
1
Making it undefined at least allows you to trap it.
If you want wrap around, be explicit about it.
1
2
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.
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
Show replies




