Reading uninit data being undefined instead of locking it to an unspecified value permits massive optimizations like MADV_FREE and more efficient register allocation/spilling. Similarly, other memory safety issues being undefined permits optimization / freedom of implementation.
Conversation
Many programs have bugs where they read data that has just been freed, but handle it being an arbitrary value. The issue is often benign with common allocators. However, with other implementations the access will fault and they crash. It's good it's not required to let it work.
2
3
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.
3
5
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
K&R C explicitly permits arbitrary implementations of overflow including an implementation that traps. It doesn't mandate two's complement or any specific set of possible implementations.
ANSI C refers to standard C containing all the explicit wording about undefined behavior.
1
1
K&R gives the compiler and hardware the ability to do whatever they want in this case. They mention that current compilers do not try to detect overflow. It's explicitly permitted to catch overflow. Per K&R, even unsigned integer overflow is allowed to be handled differently.
1
So if you want to talk about K&R C, -fsanitize=signed-integer-overflow,unsigned-integer-overflow -fsanitize-trap=signed-integer-overflow,unsigned-integer-overflow conforms to how it's defined, unlike ANSI / ISO C where only signed overflow checking is compliant with the standard.
A language that has no official spec nonetheless has an implicit spec that arises from its corpus of users. When folks like me talk about K&R C, we're talking about the implicit spec. That spec was far more restrictive than you're trying to say.
1
1
The language did have a defacto standard which is what you're using to refer to it. It doesn't need to be an international treaty to be a standard. Implementation of integer overflow also did certainly vary across hardware / compilers. Trap on overflow isn't something new either.