Live data from Hacker News

Compiling C to Safe Rust, Formalized

arxiv.org

21–30 of 173 posts

Re: Compiling C to Safe Rust, Formalized

#21
post #9
post #2

I wonder how well O3 can do just compiling C to rust in one shot

Funny, I came here to say just the opposite, that I'm glad algorithmic computing is still a thing in research and that not everything is AI. Ironically, AI is able to produce research-grade algorithms and will probably become an authority on the subject, helping take more traditional CS to the next level.

I think it would make sense to evaluate if the the 'surgical' rewrites mentioned in the article can be carried out by or assisted by an LLM based process.

Re: Compiling C to Safe Rust, Formalized

#22

Compiling a tiny subset of C, that is. It might be so tiny as to be useless in practice. I have low hopes for this kind of approach; it’s sure to hit the limits of what’s possible with static analysis of C code. Also, choosing Rust as the target makes the problem unnecessarily hard because Rust’s ownership model is so foreign to how real C programs work.

Meh, you know people are just going to throw LLMs at it and they'll be fine with it hallucinating correctish code by the ton-load. But I agree that they are going to have tough time making idiomatic Rust from random C. Like I said, correct-ish.

Re: Compiling C to Safe Rust, Formalized

#23
post #17

Earlier quoted context omitted.

Rust's ownership model is close enough for translating C. It's just more explicit and strongly typed, so the translation needs to figure out what a more free-form C code is trying to do, and map that to Rust's idioms. For example, C's buffers obviously have lengths, but in C the length isn't explicitly tied to a pointer, so the translator has to deduce how the C program tracks the length to convert that into a slice.…

Rust’s ownership model forbids things like doubly linked lists, which C programs use a lot. That’s just one example of how C code is nowhere near meeting Rust’s requirements. There are lots of others.

> Rust’s ownership model forbids things like doubly linked lists, which C programs use a lot.

It’s literally in the standard library

https://doc.rust-lang.org/std/collections/struct.LinkedList....

Re: Compiling C to Safe Rust, Formalized

#24
post #20
post #17

Earlier quoted context omitted.

Rust's ownership model is close enough for translating C. It's just more explicit and strongly typed, so the translation needs to figure out what a more free-form C code is trying to do, and map that to Rust's idioms. For example, C's buffers obviously have lengths, but in C the length isn't explicitly tied to a pointer, so the translator has to deduce how the C program tracks the length to convert that into a slice.…

Is this sarcastic? There's a reason why the lifetime checker is so annoying to people with a lot of C experience. You absolutely cannot just use your familiar C coding styles in Rust.

You’ve misread the comment.

The ownership model is close enough, but the way that model is expressed by the developer is completely arbitrary (and thus completely nuts).

Re: Compiling C to Safe Rust, Formalized

#25
post #23

Earlier quoted context omitted.

Rust’s ownership model forbids things like doubly linked lists, which C programs use a lot. That’s just one example of how C code is nowhere near meeting Rust’s requirements. There are lots of others.

> Rust’s ownership model forbids things like doubly linked lists, which C programs use a lot. It’s literally in the standard library https://doc.rust-lang.org/std/collections/struct.LinkedList....

[deleted]

Re: Compiling C to Safe Rust, Formalized

#27
post #23

Earlier quoted context omitted.

Rust’s ownership model forbids things like doubly linked lists, which C programs use a lot. That’s just one example of how C code is nowhere near meeting Rust’s requirements. There are lots of others.

> Rust’s ownership model forbids things like doubly linked lists, which C programs use a lot. It’s literally in the standard library https://doc.rust-lang.org/std/collections/struct.LinkedList....

This implementation uses unsafe. You can write a linked list in safe rust (e.g. using Rc), but it probably wouldn't resemble the one you write in C.

In practice, a little unsafe is usually fine. I only bring it up since the article is about translating to safe rust.

Re: Compiling C to Safe Rust, Formalized

#28
post #27
post #23

Earlier quoted context omitted.

> Rust’s ownership model forbids things like doubly linked lists, which C programs use a lot. It’s literally in the standard library https://doc.rust-lang.org/std/collections/struct.LinkedList....

This implementation uses unsafe. You can write a linked list in safe rust (e.g. using Rc), but it probably wouldn't resemble the one you write in C. In practice, a little unsafe is usually fine. I only bring it up since the article is about translating to safe rust.

Safe rust isn’t “rust code with absolutely 0 unsafe blocks in any possible code path, ever”. Rc uses unsafe code every time you construct one, for example.

Unsafe blocks are an escape hatch where you promise that some invariants the compiler cannot verify are in fact true. If the translated code were to use that collection, via its safe interfaces, it would still be “safe rust”.

More generally: it’s incorrect to say that the rust ownership model forbids X when it ships with an implementation of X, regardless of if and how it uses “unsafe” - especially if “unsafe” is a feature of the ownership model that helps implement it.

Re: Compiling C to Safe Rust, Formalized

#29
post #9
post #2

I wonder how well O3 can do just compiling C to rust in one shot

Funny, I came here to say just the opposite, that I'm glad algorithmic computing is still a thing in research and that not everything is AI. Ironically, AI is able to produce research-grade algorithms and will probably become an authority on the subject, helping take more traditional CS to the next level.

There's a lot of code in the world where correctness is a requirement. :)

I agree with the sibling -- I think LLMs may be able to help automate some parts of it, but humans are still 95% of it. At least for now.

Post reply on HN