Also, signed overflow being undefined rather than defined as wrapping means that more secure implementations where it traps are permitted. Passing -fsanitize=signed-integer-overflow -fsanitize-trap=signed-integer-overflow is standards compliant and used for hardening in AOSP.
Conversation
Trapping on overflow breaks lots of code that does it on purpose. Code that can’t run is more secure than code that doesn’t only in a meaningless sense.
1
That code can be fixed and the fixes are clear cut bug fixes. High quality C code is tested with ASan, TSan, UBSan, etc. and many of these issues are already being caught and fixed over time. Portable and safe C code needs to avoid relying on undefined behavior like this.
2
5
You say overflow is undefined. I say it’s defined. As a bonus CPUs say I’m right. The world needs a language that just does what the CPU does. If you don’t want that, don’t program in C.
4
2
2
C isn't defined as that language, and you're not in a position where you get to define the language. In the real world, C is deployed with various safety features taking advantage of many things being undefined and reducing portability / compatibility with those wouldn't be good.
2
5
This Tweet was deleted by the Tweet author. Learn more
The Linux kernel chooses to use a superset of standard C. It doesn't ignore the rules that it isn't disabling via those switches but rather is actively tested with ASan and UBSan, with people working to address the cases that are not permitted, usually by fixing the kernel bugs.
2
1
You’re still hung up on a false choice between a well defined spec and instrumentation/tools that alter behavior while giving you something good in return. A defined behavior for C wouldn’t stop those tools from existing.
1
The defined behavior can be trapping, which makes more sense in 2019 with software safety / security / robustness as such important issues. Hardware can and is being designed to make it efficient to catch these issues too. It can also just permit safety without using 'undefined'.
2
1
That definition would make lots of real systems stop working, so that’s clearly the wrong direction for the spec. A good spec respects its customers.
1
2
Defining it as you want would make most real systems non-compliant with the C standard by forbidding the safety features that they deploy by default including type-based CFI, basics like _FORTIFY_SOURCE, CFI, etc. It's true that C code has widespread type / memory unsafety bugs.
And lots of other bugs like unintended integer overflows, which can currently be caught by a standards compliant implementation for signed integer overflow. Clang / GCC also provide an extension to mark intended, well-defined signed (and unsigned) integer overflow when needed.