Item — HN Reader

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.

1 comments

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?

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.

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.

Not having UB in is a prerequesite for memory safety.

In theory, WG14 could make top-down decisions. But if we would decide something implementors really do not want to do, they would simply ignore the standard. And this happens. For example, we had to make some realloc corner case UB in C23 because different implementations did behave differently and no one wanted to change their implementation. But the implementors themselves are represented inside WG14, so we usually can't get consensus for such decisions in the first place. So WG14 rules the C world by finding a minimum consensus everybody can agree to and this is really the only way it can work if you have so many different players with so many different requirements. The C world is far bigger than most of us imagine.