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.
Conversation
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
Neither of us gets to choose how C is defined. You want to make it more permissive, and I would make it stricter and safer. Instead, the standard compromises between all the competing interests (portability, performance, safety) by giving implementations lots of freedom.
2
The standard creates a mess by compromising too broadly. I’m not arguing with you over what anyone is in a position to do, so that point is moot. I am proposing a standard that would make it possible to write systems code and have confidence in what it does.
1
Okay, and that's not how C is defined or how it's likely to ever be defined. You're free to make a standard for your own language based on C. I don't think what the world needs is a memory and type unsafe language that's even more permissive, but you're free to make one.
1
It’s not “more permissive”. Making something undefined doesn’t make it unpermitted.
1
Yes, it does make it more permissive. You want to forbid implementations of C that trap on out-of-bounds accesses, signed overflow, etc. which is currently permitted by the standard and widely deployed in production systems in the real world to improve safety and security.
You want to forbid memory tagging (SPARC ADI, ARM MTE), shadow stacks, type-based CFI and even very basic security features like _FORTIFY_SOURCE in fully standards compliant implementations of C. Expanding what C language allows in well-defined code is making it more permissive.
No. I want that behavior to be spec’d. The spec can say, “in the unsafe mode, this behaves like so and in the sanitizer mode it behaves like some other way”. Having a spec that defines the behavior doesn’t prevent other new behavior.
2
Folks do this all the time in well defined languages. Like, there are loads of JS use cases where the spec is intentionally bent and that’s totally ok. I especially love the embedded JS things where dynamic behavior is curtailed. That work wasn’t inhibited by the spec at all.