These issues are not the practical issues with it in the real world. Making all these little things well defined doesn't fix that C code is plagued by type and memory safety errors, which lead to software being extremely unsafe, unreliable and vulnerable. It's mostly academic.
Conversation
This Tweet was deleted by the Tweet author. Learn more
I'm not the one with a fundamental misunderstanding of how C is supposed to work. You're making an extreme misinterpretation of what I've been stating. Making C much more permissive forbids optimizations, safety improvements, portability, alternate implementation approaches, etc.
1
1
The fact that C makes type and memory safety issues along with other classes of bugs undefined is what makes it permitted to make a much more secure implementation where temporal and inter-object spatial memory safety issues are partially or even fully detected at runtime, etc.
1
1
Permitting trapping on signed integer overflow is another good example of that. If it defined signed integer overflow as guaranteed to wrap, it would disallow more secure implementations where it traps. Even saying it either wraps or strictly traps would be a safety regression.
1
Since it should permit implementations that do more efficient lazy trapping, as that's more likely to be widely adopted due to significantly better performance, especially with hardware support. It's how some next generation hardware approaches handling overflow by default.
1
i.e. hardware support for poison values, where you can still use them to perform more arithmetic (resulting in more poison values) but as soon as you actually read them in order to depend on them in some other way, it will trap.
1
Redefining C to forbid lots of important real world safety features even including extreme basics like type-based CFI, _FORTIFY_SOURCE and -fsanitize=object-size would be horrible. I think you need to think over what making it more permissive would do to safety / portability.
1
Replacing 'undefined' with stricter definitions could often be a good thing, but simply making the language more permissive and forbidding memory / type safe implementations is not a good way to do that. I'm glad the people involved in making the standard are smarter than that.
2
Saying that type-unsafe behavior results in a nasal demon is not a good way of handling the situation. If you were advocating for a C spec that mandates traps when bad things happen, then I would grant that this is a better spec, though not the one I want.
1
That's the specification that I would want, but a specification that says these things are undefined is far better than one which is incredibly permissive and forbids implementations from providing type and memory safety. Right now, you can make a very safe implementation.
And look, no one is going to succeed at getting the C standards committee to forbid widespread exploit mitigations like bounds checking (including very incomplete forms like _FORTIFY_SOURCE), type-based CFI, dynamic cast checking, etc. These safety features are widely deployed.
1
If someone wants to make signed integer overflow well-defined as wrapping, I hope there's someone there to bring up that there are broadly deployed implementations using signed integer overflow checking. It's heavily used in the Android Open Source Project.