Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

fractalfir.github.io

Post reply on HN
Print view View original

61–70 of 264 posts

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

#61

Post by tetha »

drdeca wrote: post #36
jokoon wrote: post #34

At first I read it as C to rust compiler. What is the point of compiling rust to C?

I think there are probably C compilers for more platforms than there are rust compilers. So, if you want to compile your rust project on some obscure platform that doesn’t have a rust compiler for it yet, you could compile to C and then compile the resulting C code for that platform? Just a guess.

This is a fairly common technique in compiler construction and programming language research: Don't try to emit some machine code, instead emit C or an IR for clang or GCC. And suddenly your little research language (not that rust is one) is executable on many, many platforms, can rely on optimizations the compilers can do, has potential access to debug handling, ..

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

#62

Post by widforss »

drdeca wrote: post #36
jokoon wrote: post #34

At first I read it as C to rust compiler. What is the point of compiling rust to C?

I think there are probably C compilers for more platforms than there are rust compilers. So, if you want to compile your rust project on some obscure platform that doesn’t have a rust compiler for it yet, you could compile to C and then compile the resulting C code for that platform? Just a guess.

Regarding the other way, I guess a lot of (practically) legal C wouldn't compile to Rust at all due to the language's restrictions and C's laxness, while I think all Rust could be translated to C.

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

#63

Post by lmm »

cv5005 wrote: post #49
lmm wrote: post #27

Earlier quoted context omitted.

Machine code is generally much safer than C - e.g. it usually lacks undefined behaviour. If you're unsure about how a given piece of machine code behaves, it's usually sufficient to test it empirically.

Not any different from C - a given C compiler + platform will behave completetly deterministically and you can test the output and see what it does, regardless of UB or not.

> a given C compiler + platform will behave completetly deterministically and you can test the output and see what it does, regardless of UB or not.

Sure[1], but that doesn't mean it's safe to publish that C code - the next version of that same compiler on that same platform might do something very different. With machine code (especially x86, with its very friendly memory model) that's unlikely.

(There are cases like unused instructions becoming used in never revisions of a processor - but you wouldn't be using those unused instructions in the first place. Whereas it's extremely common to have C code that looks like it's doing something useful, and is doing that useful thing when compiled with a particular compiler, but is nevertheless undefined behaviour that will do something different in a future version)

[1] Build nondeterminism does exist, but it's not my main concern

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

#64

Post by baq »

lmm wrote: post #63
cv5005 wrote: post #49

Earlier quoted context omitted.

Not any different from C - a given C compiler + platform will behave completetly deterministically and you can test the output and see what it does, regardless of UB or not.

> a given C compiler + platform will behave completetly deterministically and you can test the output and see what it does, regardless of UB or not. Sure[1], but that doesn't mean it's safe to publish that C code - the next version of that same compiler on that same platform might do something very different. With machine code (especially x86, with its very friendly memory model) that's unlikely. (There are cases lik…

CPUs get microcode updates all the time, too. Nothing is safe from bitrot unless you’re dedicated to 100% reproducible builds and build on the exact same box you’re running on. (…I’m not, for the record - but the more, the merrier.)

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

#65

Post by uecker »

lmm wrote: post #63
cv5005 wrote: post #49

Earlier quoted context omitted.

Not any different from C - a given C compiler + platform will behave completetly deterministically and you can test the output and see what it does, regardless of UB or not.

> a given C compiler + platform will behave completetly deterministically and you can test the output and see what it does, regardless of UB or not. Sure[1], but that doesn't mean it's safe to publish that C code - the next version of that same compiler on that same platform might do something very different. With machine code (especially x86, with its very friendly memory model) that's unlikely. (There are cases lik…

It is not terribly hard to generate C code that does not use undefined behavior.

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

#66

Post by adwn »

bregma wrote: post #56
pornel wrote: post #48

Earlier quoted context omitted.

It could fail if the generated C code triggered Undefined Behavior. For example, signed overflow is UB in C, but defined in Rust. Generated code can't simply use the + operator. C has type-based alias analysis that makes some type casts illegal. Rust handles alias analysis through borrowing, so it's more forgiving about type casts. Rust has an UnsafeCell wrapper type for hacks that break the safe memory model and wou…

Wait until you find out how unsafe software written in the machine language that Rust usually transpiles to is.

That's not the same, and not what pornel is talking about. The x86 ADD instruction has a well-defined behavior on overflow, and i32 + i32 in Rust will usually be translated to an ADD instruction, same as int + int in C. But a C compiler is allowed to assume that a signed addition operation will never overflow (the dreaded Undefined Behavior), while a Rust compiler must not make that assumption. This means that i32 + i32 must not be translated to int + int.

For example, a C compiler is allowed to optimize the expression a+1 to false (if a is signed), but a Rust compiler isn't allowed to do this.

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

#67

Post by CryZe »

Aurornis wrote: post #9
claudiojulio wrote: post #2

Very cool. C to Rust would be fantastic.

> 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...

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

#69

Post by olivermuty »

kreetx wrote: post #54
josephg wrote: post #19

Earlier quoted context omitted.

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.

Borrow checker, and more generally any type checkers, are essentially terminating programs ran during compilation process, thus safety guarantees given by them are ensured before the code is transformed into some target language.

Thats assuming lossless transpilation though
Post reply on HN