Hacker News Reader

Comment by aw1621107 | Hacker News Reader

> and also allows sanitizers to continue to flag it to developers so that they fix their bugs

I've never really found this argument particularly convincing; as you say, sanitizers don't have to strictly adhere to the standard, and they do in fact take advantage of this flexibility to check behaviors that "are not undefined behavior, but are often unintentional" (e.g., -fsanitize=unsigned-integer-overflow).

Makes me wonder whether "sanitizers can't flag defined behavior" is meant to be shorthand for some more nuanced position ("the false positive rate for signed overflow sanitizer checks would be too high", maybe?) or something else.

View on HN

> -fsanitize=unsigned-integer-overflow

Of course, -fsanitize=unsigned-integer-overflow isn't enabled by default, and few people use it (github code search gives 6K results for that, compared to 175K for "-fsanitize=undefined"; which to be fair is a lot higher than I expected, but still not a lot).

> Makes me wonder whether "sanitizers can't flag defined behavior" is meant to be shorthand for some more nuanced position

And signed overflow checking would have to be off-by-default too, if people were allowed to start relying on it. It'd be less "false positive rate too high", more "it disallows you to use a genuine language feature that is actually useful", defeating the point of defining signed overflow in the first place.

(imo defining signed overflow specifically for reducing attack surface from exploitable UB is a mostly-separate discussion, which should not affect core language semantics, and certainly not what users would be suggested to do)

> 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)

Clang does actually have experimental support for these - https://clang.llvm.org/docs/OverflowBehaviorTypes.html

> 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....

> In C++ perhaps, but impossible in C.

Oh, true I forgot about that.

C++ has introduced the concept of erroneous behavior for this, which is much better.

Making signed overflow EB would preclude using signed overflow for optimization though, which seems to be (correctly or not) considered an important use case.

Reply on news.ycombinator.com