Of course, -fsanitize=unsigned-integer-overflow isn't enabled by default, and few people use it
Sure, but it's still a counterexample for "you can't define it because it means sanitizers can't warn for it". Sanitizers can warn for it; you "just" get a worse signal-to-noise ratio.
It'd be less "false positive rate too high", more "it disallows you to use a genuine language feature that is actually useful"
I'm not sure I see the distinction? Flagging a correct use of a language feature as incorrect is more or less the definition of a false positive, so if intentional signed overflows get a reasonable amount of use then that'd presumably result in an unacceptably noisy check to be enabled by default.
defeating the point of defining signed overflow in the first place.
As for unsigned overflow checks I'd imagine the intent is that one would enable that particular check if you think that the corresponding overflow is more likely to be unintentional than not, and in the cases where it actually is intentional you can suppress the check.
it's still a counterexample for "you can't define it because it means sanitizers can't warn for it"
Sure, technically you can write a sanitizer for anything. It just becomes less a "sanitizer" you can always recommend everyone everywhere use, and more of just a heuristic thing that only really works if you design your code for its arbitrary desires.
and in the cases where it actually is intentional you can suppress the check.
imo it'd be nice to have separate types for wrapping and non-wrapping integers for that, so that you have actual language-level semantics and an easy way to mix things (e.g. wrapping arith for hashing, mixed with non-wrapping arith for loop index or whatever) instead of suppressions.
It just becomes less a "sanitizer" you can always recommend everyone everywhere use, and more of just a heuristic thing that only really works if you design your code for its arbitrary desires.
Sure, and that's basically what I was wondering about with respect to "can't define it" being shorthand for something else
imo it'd be nice to have separate types for wrapping and non-wrapping integers for that
I think I'd agree, though I'd imagine it's a bit late for such things to be deeply integrated into the language. At least making your own isn't horrendously difficult.
Sure, and that's basically what I was wondering about with respect to "can't define it" being shorthand for something else
Eh, I'd say it's still the same thing; can't define a sanitizer for it if what you define isn't a sanitizer. Depends on a specific definition of "sanitizer" though.
At least making your own isn't horrendously difficult.
In C++ perhaps, but impossible in C. (and there are still some funky edge-cases where multiplying two `uint16_t`s can overflow due to implicit promotion to signed int; C's _BitInt solves at least that)
Depends on a specific definition of "sanitizer" though.
Hrm, I suppose a general definition would be something that you use to check for certain (unintended?) runtime behaviors? Though I also feel that could include hardened implementations and stuff like valgrind....
Comments
Sure, but it's still a counterexample for "you can't define it because it means sanitizers can't warn for it". Sanitizers can warn for it; you "just" get a worse signal-to-noise ratio.
I'm not sure I see the distinction? Flagging a correct use of a language feature as incorrect is more or less the definition of a false positive, so if intentional signed overflows get a reasonable amount of use then that'd presumably result in an unacceptably noisy check to be enabled by default.
As for unsigned overflow checks I'd imagine the intent is that one would enable that particular check if you think that the corresponding overflow is more likely to be unintentional than not, and in the cases where it actually is intentional you can suppress the check.
Sure, technically you can write a sanitizer for anything. It just becomes less a "sanitizer" you can always recommend everyone everywhere use, and more of just a heuristic thing that only really works if you design your code for its arbitrary desires.
imo it'd be nice to have separate types for wrapping and non-wrapping integers for that, so that you have actual language-level semantics and an easy way to mix things (e.g. wrapping arith for hashing, mixed with non-wrapping arith for loop index or whatever) instead of suppressions.
Sure, and that's basically what I was wondering about with respect to "can't define it" being shorthand for something else
I think I'd agree, though I'd imagine it's a bit late for such things to be deeply integrated into the language. At least making your own isn't horrendously difficult.
Eh, I'd say it's still the same thing; can't define a sanitizer for it if what you define isn't a sanitizer. Depends on a specific definition of "sanitizer" though.
In C++ perhaps, but impossible in C. (and there are still some funky edge-cases where multiplying two `uint16_t`s can overflow due to implicit promotion to signed int; C's _BitInt solves at least that)
Clang does actually have experimental support for these - https://clang.llvm.org/docs/OverflowBehaviorTypes.html
Hrm, I suppose a general definition would be something that you use to check for certain (unintended?) runtime behaviors? Though I also feel that could include hardened implementations and stuff like valgrind....
Oh, true I forgot about that.