Live data from Hacker News

Rust to C compiler – 95.9% test pass rate, odd platforms

fractalfir.github.io

11–20 of 264 posts

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#12

But does it carry the Rusty guarantees?

If the transpilation itself is bug-free, why not? For static guarantees, provided we transpile Rust code that already compiles on a normal Rust compiler, the guarantees are already checked and there, and the dynamic ones such as bounds checking can be implemented runtime in C with no problems.

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#15
post #13

Is it LLVM IR --> C? Or Rust AST to C?

Found the answer in the project readme.

> My representation of .NETs IR maps nicely to C, which means that I was able to add support for compiling Rust to C in 2-3K LOC. Almost all of the codebase is reused, with the C and .NET specific code only present in the very last stage of compilation

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#16

How is this not dangerous? How can one be assured that all of the compile-time safety features of the Rust compiler are still in effect? Handwaving does not help.

It's as safe as LLVM IR is safe, assuming you trust the LLVM IR -> C translation step.

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#17

But does it carry the Rusty guarantees?

If the transpilation itself is bug-free, why not? For static guarantees, provided we transpile Rust code that already compiles on a normal Rust compiler, the guarantees are already checked and there, and the dynamic ones such as bounds checking can be implemented runtime in C with no problems.

this assumes the rusty guarantees are transitive. There's no reason to believe it isn't, but it'd be nice to see some sort of proof, or at least an argument for it.

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#19
post #17

Earlier quoted context omitted.

If the transpilation itself is bug-free, why not? For static guarantees, provided we transpile Rust code that already compiles on a normal Rust compiler, the guarantees are already checked and there, and the dynamic ones such as bounds checking can be implemented runtime in C with no problems.

this assumes the rusty guarantees are transitive. There's no reason to believe it isn't, but it'd be nice to see some sort of proof, or at least an argument for it.

Should be. The rust borrow checker has no runtime component. It checks the code as-is before (or during) compilation.

Arguably it’s not the compiled binary that’s “safe”. It’s the code.

Post reply on HN