Hacker News Reader

Hacker News

Comment by qw3rty01 | Hacker News Reader

Parent Full thread

qw3rty01

it doesn't convert pointers to references, it just uses pointers, so the borrow checker isn't invoked.

View on HN

For the non-Rust programmers here, does that mean you don't get Rust's memory safety with this transpiler?

That's correct. There's no way to translate arbitrary C to memory safe code.

If you could, you wouldn't need Rust in the first place.

That's a good point. I feel stupid for asking now :D

You can compile the C code to WASM and then compile the WASM to safe Rust (I wrote a prototype for this and it works). Though as with all WASM, it protects the environment from the C code, but the C code can still corrupt its own WASM memory. iirc Firefox is even starting to use this approach to sandbox some of its components (though they compile the WASM back to C).

There are non-standard extensions to C syntax that provide some amount of safety. It might be interesting to implement support for those within c2rust.

But what if the arbitrary C code was memory-safe to begin with?

Then I assume you'd get safe, "unsafe" Rust code.

Fun fact: in order to be valid, Rust code in an `unsafe` block must uphold all of Rust's invariants. So (correct) Unsafe Rust is the only code written in Rust that's explicitly safe.

Idiomatically the unsafe block should have a comment explaining why this is actually fine, and if it's an unsafe public API it should have a doc-comment explaining how it can be used safely by other unsafe code.

If you're using unsafe functions to flag something other than Rust's safety considerations (e.g. Rust's core concept doesn't care that this flag bit disables the interrupt controller, and thus if you get it wrong now the product doesn't work, but you probably do so let's mark that "unsafe") the same likely applies for that too.

One of the things I like in Jon Gjengset's live coding Youtube videos is that he takes the time to write such comments, which means both the final code and the live session explain why he thinks this is safe, and once in a while there's a realisation while doing this - aha, this is the wrong way to do it, we need to change other things.

But can we get 80% there and then have a human help out?

> But can we get 80% there and then have ma human help out?

The problem is that for complex enough projects, the architectural redesign is considerably more demanding than a "remaining 20%". I can imagine it also being quite irritanting, due to shortcuts one may take in C taking advantage of implicit application logic (independently of them being warranted or not), that can't be directly translated due to the Rust strictness.

I wonder if the brainiacs at OpenAI could train a neural net on human-written C -> Rust translations.

From another non-rust programmer: all bugs you could write in C will still be there in the transpiled code and the parts that happen to not be bugs will still look as indistinguishable from bugs as they did before. Likely even more indistinguishable than before, because chances are you are better at reading idiomatic C than at reading the anti-idiomatic rust created by the transpiler. But there will likely be some low-hanging fruits of code that can subsequently be changed into idiomatic rust that simply cannot encode certain classes of bugs (without becoming as un-idiomatic as the transpiler output).

The idea here is you get the c code transpiled verbatim into unsafe rust code.

It is your job to then make it safe rust code :).

Edit: spelling

Correct, although it looks like converting some parts to safe code may be a future goal

What they've stated previously is that they plan to go with the approach of "compile C to unsafe Rust" and "compile unsafe Rust to safe Rust" as two separate things that could be chained together. I don't remember if it's meant to be literally another tool or just the general approach, but seems very interesting and sensible to me!

Reply on news.ycombinator.com