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.
Conversation
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.
2
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
Sure, and I have no problem with defining all these cases of undefined behavior including type and memory unsafety as trapping. That makes a lot of sense to adapt C to the modern world and evolving needs which have made it into a huge liability. I don't want undefined behavior.
However, I'd rather have undefined behavior than safe implementations being treated as non-compliant or as lesser supported implementations. Reducing portability to safe implementations would be a massive regression, harming safety and security in the real world. Not a good move.
1
I don't think making it even harder to improve safety is something that should happen. It's a good thing that signed overflow is treated as a bug unless a non-portable dialect like passing -fwrapv is used. People who want the permissive behavior have it already for Clang / GCC.