misra-rust VS SaferCPlusPlus-AutoTranslation2

MISRA and Ferrocene are not really related.

MISRA is, as you say, a set of rules for writing C code, that restrict what you can do.

Ferrocene is a qualified compiler. You write any normal Rust code you want: it's still the upstream Rust compiler. There are no restrictions.

Incidentally, someone has compared what MISRA does to what Rust does: https://github.com/PolySync/misra-rust/blob/master/MISRA-Rul...

Given that they can't repeat the MISRA stuff there, it's a bit disjoined, but it sure is interesting!

A fun github repo: "what would MISRA look like applied to Rust" https://github.com/PolySync/misra-rust/blob/master/MISRA-Rul...

(They're comparing with the C version, not the C++ version...)

> There are huge swathes of MISRA which forbid things which not only aren't possible in Rust or SPARK

I can't vouch for its accuracy, but https://github.com/PolySync/misra-rust

When it comes to MISRA C, it is interesting to note how many (a majority) of its rules do not apply or have native enforcement[1].

You might have also seen the AUTOSTAR Rust in Automotive Working Group announcement recently[2].

[1]: https://github.com/PolySync/misra-rust/blob/master/MISRA-Rul...

[2]: for some reason the announcement was removed from the "News and events" site, https://webcache.googleusercontent.com/search?q=cache%3Ahttp... but it is still available as a PDF https://www.autosar.org/fileadmin/user_upload/20220308_RustW...

There's actually already a comparison: https://github.com/PolySync/misra-rust/blob/master/MISRA-Rules.md

Rust makes quite a few things more rigorous (e.g. pairing allocations with deallocations and reference validity). It basically fulfills the job of a static analyzer baked into the language.

It's also a vastly more analyzable language (in that its syntax is reasonably unambiguous and there's no dynamic runtime in play) and it can be integrated well.

Toolchain quality (error reporting, built in testing, awareness of primitives like "libraries", etc.) is also a huge strong point.

We're reasonably confident that we can use safe Rust as is, with strong guidance on how to do unsafe Rust.

For a tangible investigation of that space, PolySync has a project that has a look at MISRA rules from a Rust perspective. https://github.com/PolySync/misra-rust/blob/master/MISRA-Rul...

Ada is a good example here: the language has not evolved something like MISRA-C (it has evolved SPARK for formal verification, but I see that differently).

Hi pizlonator, I'm working on a solution with similar goals (I think), but a bit of a different approach. It's a tool that auto-translates[1] (reasonable) C code to a memory-safe subset of C++. The goal is to get it reliable enough that it can be simply inserted as an (optional) build step, so that the source code can be maintained in its original form.

I'm under the impression that you're more of a low-level/compiler person, but I suggest that a higher level language like (a memory-safe subset of) C++ actually makes for a more desirable "intermediate representation" language, as it's amenable to maintaining information about the "intent" of the code, which can be helpful for optimization. It also allows programmers to provide manually optimized memory-safe implementations for performance-critical parts of the code.

The memory-safe subset of C++ is somewhat analogous to Rust's in terms of performance and in that it depends on a non-trivial static checker, but it imposes less onerous restrictions than Rust on single-threaded code.

The auto-translation tool already does the non-trivial (optimization) task of determining whether any (raw) pointer is being used as an array iterator or not. But further work to make the resulting code more performance optimal is needed. The task of optimizing a high-level "intermediate representation" language like (memory-safe) C++ is roughly analogous to optimizing lower-level IR languages, but the results should be more effective because you have more information about the original code, right?

I think this project could greatly benefit from the kind of effort you've displayed in yours.

[1]: https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

Part of the reason the proposed static analyzer has to be so ambitious is because it's trying to validate (i.e. verify as safe) as much existing/legacy code as possible. An alternative approach is to autoconvert existing code to new code that is easier to verify as safe. One advantage of this approach is that in instances where you cannot (yet) statically verify safety, you can convert to (new) elements that may resort to run-time safety mechanism when necessary. With access to the full range of safety-performance tradeoffs, this approach can (fully) safen a much larger set of legacy code then any static analyzer alone could.

There's also some support for autoconverting legacy C code that is not performance critical to use the library and conform to a safe subset of C++.