Item — HN Reader

The thing with UB in C is that it was traditionally seen also as a possible extensions point, so someone else can come in and define the behavior, e.g. POSIX does it for some. But yes, we understood that this is not how people look at this anymore, and hence we will remove it.

But I do not see how Rust helps? Rust has no standard and its reference implementation is subject to change. How did you convince yourself that what ISO C leaves not-standardized is any worse than what is not being standardized in the first place? There seems to be a double-standard here.

1 comments

The comparison isn't with rust today, but the long term differences between the languages. Rust has a straightforward path to rectifying the standardization issue and enough community momentum to succeed.

For example, Rust has an in-progress specification, here's the (currently empty) repo: https://github.com/rust-lang/spec. There's also MIR, a de-sugared internal representation that's sufficiently well specified to build formal models of (see https://github.com/rust-lang/a-mir-formality and https://github.com/rust-lang/miri), as well as the ferrocene spec (https://spec.ferrocene.dev/general.html) that's suitable for certification authorities (if not actually useful) and of course the rust reference/RFCs that are actually usable by people.

Plus, the fact that everyone in the rust community has standardized on one compiler and one package manager (for better or worse) means that the language team has a much better insight into specification breakages than the ISO process of languages like C and C++.

I can start writing stuff today and be confident that any changes will be minor if necessary when the language catches up.

I'm more than happy to have this discussion over email if you want to move it off HN, too.