So you're saying for two of the three arbitrary rules I mentioned you need additional tooling for analysis... sure sounds like my initial point.
But that's not even the point.
> If anything I'd say the contrary is true, people overestimate what MISRA achieves, big chunks of it could be summarised as "Don't do things that are obviously a terrible idea".
This is exactly what I mean. You're missing the point of MISRA if you think that's an overestimation or just to make managers happy... MISRA is often for life or death, and it's not even going as far as the random ISO standards that end up applying on top of it in some domains. It might be "obviously terrible" stuff, but very excellent developers end up doing it anyways sometimes, that's just being human.
The ground work to even verify a Rust toolchain doesn't even exist, (the closest I could find is a WIP https://ferrous-systems.com/blog/sealed-rust-the-pitch/) so I'm guessing everyone forcing this is likely rolling their own setup of additional tools?
If you don't work on ABS controllers and you work at somewhere like Tesla where the bar for safety is a little lower in the name of using new shiny things, by all means use Rust. But I wouldn't do that in a million years. I simply don't buy that using established MISRA C tooling is less safe than rolling your own lint setup.
> So you're saying for two of the three arbitrary rules I mentioned you need additional tooling for analysis
Sure, if you consider Clippy "additional tooling" for Rust.
As I understand it, MISRA rules (those which are clearly decidable) are also not enforced by the compiler but instead require a separate toolchain, and not one that's supplied by default with your compiler either.
> But that's not even the point.
> [...] MISRA is often for life or death
It's far from clear whether MIRSA is "life or death". Some MISRA rules correlate well to serious programming mistakes, most not so much, but they do pad the MISRA ruleset which is commercially important. There have been real studies about this, they don't come away with the conclusion you seem to expect.
> It might be "obviously terrible" stuff, but very excellent developers end up doing it anyways sometimes, that's just being human.
This is half true. There are things that are a bad idea, which are easy in C and so real people will do them, and a few of these are caught by MISRA rules. None of those things is easy (many aren't even possible) to do in modern languages. Or indeed, in Ada. MISRA is a band aid on a hand C programmers have put through a band saw. "Let's not use C" is a better fix than "Let's use MISRA".
I mentioned the value of assignment as an example, clearly assignment shouldn't have a value, it doesn't in Ada, and it doesn't in Rust, or Swift. When your hypothetical "just human" developer tries to use the value of an assignment in C that works but in these other languages it won't compile. Whereas in C we need MISRA rules to forbid this bad idea.
Let's try another one. MISRA forbids declaring variables in the body of a switch. You can't do anything similar in languages like Rust or Ada because it's crazy. Nobody does it in C either, but they could and so MISRA forbids it just in case. But once again, MISRA isn't adding any real value here (except to tool sellers) by telling people not to do things that aren't done.
I can't speak to any of the "random ISO standards". To the extent they're trying to force C into being a reasonable language to write safety critical software it seems like a waste of time to me. If they're mostly about Software Engineering then that doesn't lose applicability when you switch to a better language.
But that's not even the point.
> If anything I'd say the contrary is true, people overestimate what MISRA achieves, big chunks of it could be summarised as "Don't do things that are obviously a terrible idea".
This is exactly what I mean. You're missing the point of MISRA if you think that's an overestimation or just to make managers happy... MISRA is often for life or death, and it's not even going as far as the random ISO standards that end up applying on top of it in some domains. It might be "obviously terrible" stuff, but very excellent developers end up doing it anyways sometimes, that's just being human.
The ground work to even verify a Rust toolchain doesn't even exist, (the closest I could find is a WIP https://ferrous-systems.com/blog/sealed-rust-the-pitch/) so I'm guessing everyone forcing this is likely rolling their own setup of additional tools?
If you don't work on ABS controllers and you work at somewhere like Tesla where the bar for safety is a little lower in the name of using new shiny things, by all means use Rust. But I wouldn't do that in a million years. I simply don't buy that using established MISRA C tooling is less safe than rolling your own lint setup.