Conversation

This Tweet was deleted by the Tweet author. Learn more

Replying to

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

Replying to

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

Replying to

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

Replying to

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

Replying to

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

Replying to

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

Replying to

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

Replying to

We have enough problems with software safety / security without rolling back lots of the progress that has been made. It's far easier to introduce signed overflow checking than unsigned *because* it's undefined, considered a bug and detected by static and dynamic analysis tools.

2

1

Filip Jerzy Pizło

Replying to

You can still add that if you want and say that you're violating the spec by doing so. That would be more honest, since you *are* breaking lots of code if you do that.

1

Replying to

Except it's not violating the specification, and it's the code breaking type and memory safety that's clearly defined and acknowledged as buggy. The specification of C agrees with those safer implementations, not with people who want the language to be more permissive.

8:18 PM · Apr 16, 2019Twitter Web Client

Replying to

It would not be "more honest" to say that breaking type and memory safety is well-defined. These kinds of safety features are broadly deployed. It's how C is implemented / used in the real world. It doesn't work the way you want it to in practice, not just due to compiler opt.