Conill: The long-term consequences of maintainers’ actions

Personally I'm somewhat annoyed at the MariaDB folks about this. Didn't we all learn anything from the last time a transition had a deadline? Like, Y2K?

2038-01-19Z03:14:07 will be a freakin' heap of fun …

This hasn't been that much of an issue for other Linux distributions. Yes, newer software requires newer Rust, but stable distributions typically keep the same base version of Rust and the same base version of other software.

This issue would only apply to a distribution that wants to keep Rust fixed at a specific version for 2 years, but wants to do not just security/bugfix updates but actual *feature* updates of other software. That isn't going to work, but it doesn't work with other software either: new feature releases of software often need upgrades to their dependencies.

If you want to freeze one version of Rust for 2 years, freeze the software depending on it as well. And it's absolutely reasonable to expect software written in Rust to not add requirements on new features in bugfix/security releases.

Here's what cryptography currently says about their Rust requirement:

"The current minimum supported Rust version is 1.41.0."

1.41 was released in January 2020, and as I write this it's September 2021 and the current Rust is, I think 1.55. So, although "the Rust ecosystem is rapidly evolving" that's not inherited from cryptography. They are clearly willing to live with a much impoverished older Rust in order to not burden people with constant compiler upgrades. Alpine is choosing not to take advantage of that.

It seems to me that Alpine absolutely *could* pick a Rust version to ship in main, even if they also ship a newer one for community. If it won't do this, it seems a shame to blame cryptography for it, when it is not of their doing. If some exciting new feature in community required some C++ 20 feature and thus a very new GCC that isn't in main, would Alpine now blame all the C programs in Alpine for requiring a C compiler, even though they don't need this very new version?

MISRA is to a considerable extent making up for inadequacies or outright failings in C. Not so long ago somebody wrote on Hacker News that their safety-critical firmware is in Rust and for certification they were asked to provide some similar document to MISRA so, they just took the MISRA C doc and crossed out all the parts which were irrelevant for Rust, which, of course, is most of the MISRA C document. They're not kidding.

Let's take MISRA's rules 16.x - MISRA jealously guards copyright over their document and so I shan't recite any of it, but all of these 16.x rules are about C's switch statement. Now, a very naive programmer might say "Rust doesn't have switch so that's irrelevant" and of course that won't do at all, MISRA isn't worried about the specific word *switch*. But, when we look at Rust's match we see that it covers off almost all of MISRA's concerns, not as optional warnings, but as facets of the core language design.

Some of the 16.x rules are forbidding things no sane C programmer would do, and many would be surprised to discover are legal, such as trying to declare variables in one part of a switch and then use them in a different part even though presumably either declaration or usage won't happen when the statement is executed. Sure enough these things aren't legal Rust. But what's much nicer is that Rust also covers off some MISRA rules that apply to real C code that real programmers write. MISRA is worried about two things C programmers actually do that can hide terrible faults. Falling through, and inexhaustive matching. The C rules cover these by requiring break; religiously for each clause, and by requiring default religiously in every switch statement.

For Rust's match there is no fallthrough, so MISRA needn't forbid it, and all matches are exhaustive. If your match isn't exhaustive it won't compile. In fact Rust goes further, for API stability Rust provides #[non_exhaustive] enumerations which says, as the programmer of this data structure I don't promise I listed all the options yet, and so if you match on this, you must have a default case. For any other structures, you can't add a default case (it's redundant and causes a compiler error) if you in fact exhaustively handled every case. So, you get the benefit of MISRA's exhaustiveness *and* the benefit of common C compiler warnings for unnecessary default that often must be disabled for MISRA code.

One last 16.x rules stands out. MISRA really wants you to write the default case last, or first, but certainly not in the middle where you might lose it. It seems as first as though Rust has no similar rule, and we might need a lint here. But no! If you try to write your default case before other cases in Rust they are made redundant, and the compiler warns you this is a bad idea. You can ignore that warning, but MISRA elsewhere tells you to act on all the warnings if possible.

Now of course many MISRA directives (in particular) can't be trivially enforced by tools, human judgement is required. But even here Rust is often far ahead of C. For example MISRA wants you to document and test things, Rust's infrastructure automatically infers Markdown format documentation, one extra / in the comment above your function and it goes from merely commentary in the source code to HTML documentation that's automatically built for publication. If you write *example code* in that comment just in the ordinary way you would with Markdown, the test infrastructure automatically tries to run the code to check it actually works at the same time it runs any actual unit tests your wrote.