[stncls]

I agree with the author's general assessment, but I have issues with the... pedagogy of this post.

1. The tone of the article implies the author is taking sides. Specifically, they root for the poor developers, against the evil standard committee and compiler writers. But for context, the author is currently co-editor for the C standard committee ("WG14"). This is important because the post contains lots of humorous language and irony, which can be disorienting without this context.

2. The author correctly points out that some criticisms of UB come with exaggerate levels of passion. However, again, this verbose and "fun" article full of analogies is not helping the cause.

3. Namely, whichever side you are on, UB is subtle and would benefit from simpler exposition. The whole "Sledgehammer" explanation towards the end of the article could be summarized as: "UB does not invalidate just the statement or value that contains it. Invoking UB invalidates the whole program." The author being on the standard committee should add, I think, a sense of responsibility regarding how they communicate.

In general I think that the whole discussion around UB would benefit from serious and dispassionate studies of the costs/benefits for the various types of UB, and avenues for improvement.

[uecker]

I like to add that WG14 accepted my comment into the current draft standard that clarifies that UB does - in fact - not invalidate the whole program, and can not affect observable behavior that comes before it.

[tialaramex]

Mmm. I am not enthusiastic about choices to explain UB as actually not that bad. Even when they're strictly correct they're too often likely to mislead exactly the audience who needed the warning.

There's a C++ talk by Alistair Meredith which ends up saying that UB can't delete client files unless you the programmer wrote code to delete those files...

[uecker]

Or a hacker wrote the code, overflowed the stack and inserted the code, I guess.

But note that C++ doubled down on the idea UB invalidates the whole program.

But I also disagree that UB is the problem. It simply means the ISO C standard did not define something. A compiler can still do something perfectly safe in most cases. And in fact, many can do this with the right options. Users must learn to use these features.

[tialaramex]

It is true that, in principle, a compiler could choose to provide a defined behaviour for these cases which are marked Undefined with some engineering effort and of course potentially enormous performance cost. This would not be possible for IFNDR (because Rice's theorem) but it would be possible for Undefined Behaviour.

"Must learn to use these features" was a reasonable strategy for, say, the Apollo missions. The astronauts are very smart, very motivated, they're heavily supervised and working as a team, we can "just" train them to do it properly and if they don't they all die, if such training saves us $100M and five years R&D compared with idiot-proofing the rocket it's an excellent trade.

It's not OK for everyday tools and activities. The reality, whether we like it or not, is that C and C++ are widely used across many industries by people with greater or less skill and experience. As a result "Must learn" is a guarantee of failure. The language needs to define this properly, or the language must not be used.

Also, once we're out of the ISO C standard and requiring vendor options, much of the justification for C falls away pretty rapidly. "It's an ISO standard" is gone, "Works on all platforms" is gone, "Common tooling works" is gone. If we're giving up all these things, why not get the benefits we could have obtained in exchange from a language like Rust?

[uecker]

Not just in principle. Compilers do have flags that turn UB into defined behavior (not all UB but e.g. signed overflow) and this often does not have high overhead. Users must learn turning on certain features. I do not think this is rocket science, it is more like putting on the seat belt.

An ISO standard will always be just minimum requirements, simply because there are too many different requirements out there and it is created by consensus. It is not the ruling committee of C that could decide top-down what the language is. If users do not drive the change bottom-up by demanding improvements from their compiler vendors, it will not happen. Luckily, this is happening and compilers get more and better features for safety now. I agree though that defaults are still poor and for some problems there is still no good solution.

If somebody wants to use Rust, why not? I do not like it for a variety of reasons, but that it is safer by default (with respect to memory safety - which is not everything) is good. I personally also want to have this in C.

[tialaramex]

The thing we care about in this context is more specific than memory safety, Rust's safe subset lacks Undefined Behaviour entirely. In some places that's related to memory safety, but by no means all of them.

I don't buy the claim that WG14 can't do top-down decisions. Like at WG21 this is a convenient fiction, offered when they're reluctant to do what is asked, and immediately forgotten when it gets in the way of something they want to do.

[dent9876543]

Or, presumably, linked a library that did that same thing...

...like, uh, libc or something...

[the_mitsuhiko]

Maybe I'm unreasonable optimistic, but that sounds quite significant.

[stncls]

Yes, a step in the right direction for C2x, thank you for that.