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.
Compiling C to Safe Rust, Formalized
21–30 of 173 posts
Re: Compiling C to Safe Rust, Formalized
#22Compiling 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.
Re: Compiling C to Safe Rust, Formalized
#23Earlier 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.
It’s literally in the standard library
https://doc.rust-lang.org/std/collections/struct.LinkedList....
Re: Compiling C to Safe Rust, Formalized
#24Earlier 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.
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
#25Earlier 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....
Re: Compiling C to Safe Rust, Formalized
#26Re: Compiling C to Safe Rust, Formalized
#27Earlier 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....
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
#28Earlier 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.
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
#29I 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 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.
Re: Compiling C to Safe Rust, Formalized
#30Note that this is done for “existing formally verified C codebases” which is a lot different from typical systems C code which is not formally verified.