> C to Rust would be fantastic.

This would have to go into one big unsafe block for any nontrivial program. C doesn’t convey all of the explicit things you need to know about the code to make it even compile in Rust.

I once implemented a WASM to Rust compiler that due to WASM's safety compiles to fully safe Rust. So I was able to compile C -> WASM -> Rust and ended up with fully safe code. Though of course, just like in WASM, the C code is still able to corrupt its own linear memory, just can't escape the "sandbox". Firefox has employed a similar strategy: https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...

I'd love to check that out. Did it unroll a wasm interpreter into wasm_op function calls?

There's no interpreter, I just map each instruction to equivalent Rust code. Linear memory is accessed through a trait.

The compiler is here: https://github.com/CryZe/wasm-to-rust

I have an example of a GameBoy emulator compiled from AssemblyScript to WASM to Rust here: https://github.com/CryZe/wasmboy-rs/blob/master/src/wasm.rs

That is super cool!

Have you run into any limitations?

Have you tried running in loop, wasm->rust->wasm->rust ?

This is not-unlike unrolling an interpreter. There was a lua2c project that did something similar.

If your translator is correct, the rust front end enforces the semantics of rust then C implements them. It's as safe as any other implementation.

If that feels uncomfortable, consider that x64 machine code has no approximation to rust safety checks, and you trust rust binaries running on x64.

"Correct" is doing some heavy lifting here but generally people seem willing to believe that their toolchain is bug free.

They are discussing C to Rust, not the topic of the post. Rust would need to guess the semantics of the original C.

Mark Russinovich recently gave a talk at a UK Rust conference that mentioned Microsoft's internal attempts at large scale C->Rust translation, https://www.youtube.com/watch?v=1VgptLwP588

Note the AI part of the tooling.

Tools like those exist. The problem with them is that they use unsafe blocks a lot, and the code usually isn't very idiomatic. Translating global variable state machines into more idiomatic Rust state machines based on things like named enums, for instance, would be very difficult.

With the help of powerful enough AI we might be able to get a tool like this, but as AI still very much sucks at actually doing what it's supposed to do, I don't think we're quite ready yet. I imagine you'd also need enough memory to keep the entire C and Rust code base inside of your context window, which would quickly require very expensive hardware once your code grows beyond a certain threshold. If you don't, you end up like many code assisting LLMs, generating code independently that's incompatible with itself.

Still, if you're looking to take a C project and extend it in Rust, or perhaps slowly rewrite it piece by piece, https://c2rust.com/ is ready for action.

See https://github.com/immunant/c2rust

What benefit would you envision from this?

There is DARPA program called TRACTOR to pursue this:

https://www.darpa.mil/news/2024/memory-safety-vulnerabilitie...

1. It means you don't need C code & a C compiler in your project any more, which simplifies infrastructure. E.g. cross compiling is easier without any C.

2. You can do LTO between Rust and the C->Rust code so in theory you could get a smaller & faster executable.

3. In most cases it is the first step to a gradual rewrite in idiomatic Rust.