5 ms·

How to translate a large C project to Rust

158 points by vmbrasseur 10y ago

drewm1980 10y ago
This is a really cool project! Still very early stages though; in the article he says he's "only" translated 6% of CVS to rust. I wonder if corrode is already good enough for translating very low level numerical, i.e. imaging processing code...
duneroadrunner 10y ago
For the author: You might consider using SaferCPlusPlus[1] as an intermediate step. Most C code translates easily (and automatably if you're already parsing the C code) into SaferCPlusPlus. This already gives you memory safety, if that is the goal. Next, you can translate to "rustesque" SaferCPlusPlus. SaferCPlusPlus provides elements (pointer types) that (loosely) correspond to Rust elements [2]. The borrow checker's rule of "mutable reference exclusivity" would have to be additionally self-imposed. As you know, this is the hard (difficult to automate) part, but the nice thing is that even partially completed translations/rustifications would remain fully functional (and memory safe). The idea is that "rustified" SaferCPlusPlus code should translate to Rust fairly easily. There seems to be some skepticism of the notion of a "rusty" C/C++ subset that could be easily translated to valid Rust. The claim seems to be that "lifetime annotation" is essential to the way Rust achieves memory safety without run-time overhead. But others point out that explicit lifetime annotation is not required to evaluate memory safety [3]. It just allows the programmer to express additional intent/expectations about object lifetimes. Particularly for an application like CVS, I think translation to SaferCPlusPlus is clearly the more expedient solution. Again, the benefits of (intermediate) translation to SaferCPlusPlus: i) You get memory safety in step 1, and ii) all intermediate steps remain functional and memory safe. [1] https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus#safercplusplus-versus-rust https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp... [3] http://stackoverflow.com/questions/31609137/why-are-explicit-lifetimes-needed-in-rust#31612025 http://stackoverflow.com/questions/31609137/why-are-explicit...
- shandor 10y ago
  Sorry, but I really have to say that I think adding a waypoint through yet another language can't be a good thing. You're probably much better served by using the time saved from the second rewrite on the actual rewrite (C to Rust) you want to do, giving yourself more time to make it right.
- obastani 10y ago
  This seems like a cool idea! Are there tools to automate the translation from C to SaferCPlusPlus?
  - duneroadrunner 10y ago
    Not yet, unfortunately. It might be a while before I get a chance to address it, so if anyone out there is looking for a project, it should be fairly straightforward. At least compared to tools like the subject of this post that engage in some non-trivial semantic reasoning. :)
- dbaupp 10y ago
  > But others point out that explicit lifetime annotation is not required to evaluate memory safety [3]. I think you've extrapolated a bit too much from that answer: the code still has to be semantically lifetime-correct, even if the annotations don't need to exist syntactically. Code that wasn't written with Rust-style lifetimes in mind (even if they're not literally written in the code) is unlikely to automatically satisfy the rules statically, so unless SaferCPlusPlus is using a custom compiler that runs Rust-like rules on the code and flags violations, I would expect a lot of such code is only dynamically correct. > [2] https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp.. https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp.... A few points: - what do you mean by rebindable and non-rebindable references? That is not terminology Rust uses at all, and so it isn't clear what this is referring to. - The restriction on multiple aliasing for mutable references is not just to avoid objects being deallocated, it avoids things like iterator invalidation and concurrency problems like data races.
  - 10y ago

158 points by vmbrasseur 10y ago

drewm1980 10y ago

This is a really cool project! Still very early stages though; in the article he says he's "only" translated 6% of CVS to rust. I wonder if corrode is already good enough for translating very low level numerical, i.e. imaging processing code...

duneroadrunner 10y ago

For the author: You might consider using SaferCPlusPlus[1] as an intermediate step. Most C code translates easily (and automatably if you're already parsing the C code) into SaferCPlusPlus. This already gives you memory safety, if that is the goal. Next, you can translate to "rustesque" SaferCPlusPlus. SaferCPlusPlus provides elements (pointer types) that (loosely) correspond to Rust elements [2]. The borrow checker's rule of "mutable reference exclusivity" would have to be additionally self-imposed. As you know, this is the hard (difficult to automate) part, but the nice thing is that even partially completed translations/rustifications would remain fully functional (and memory safe). The idea is that "rustified" SaferCPlusPlus code should translate to Rust fairly easily. There seems to be some skepticism of the notion of a "rusty" C/C++ subset that could be easily translated to valid Rust. The claim seems to be that "lifetime annotation" is essential to the way Rust achieves memory safety without run-time overhead. But others point out that explicit lifetime annotation is not required to evaluate memory safety [3]. It just allows the programmer to express additional intent/expectations about object lifetimes. Particularly for an application like CVS, I think translation to SaferCPlusPlus is clearly the more expedient solution. Again, the benefits of (intermediate) translation to SaferCPlusPlus: i) You get memory safety in step 1, and ii) all intermediate steps remain functional and memory safe. [1] https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus#safercplusplus-versus-rust https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp... [3] http://stackoverflow.com/questions/31609137/why-are-explicit-lifetimes-needed-in-rust#31612025 http://stackoverflow.com/questions/31609137/why-are-explicit...

shandor 10y ago
Sorry, but I really have to say that I think adding a waypoint through yet another language can't be a good thing. You're probably much better served by using the time saved from the second rewrite on the actual rewrite (C to Rust) you want to do, giving yourself more time to make it right.
obastani 10y ago
This seems like a cool idea! Are there tools to automate the translation from C to SaferCPlusPlus?
- duneroadrunner 10y ago
  Not yet, unfortunately. It might be a while before I get a chance to address it, so if anyone out there is looking for a project, it should be fairly straightforward. At least compared to tools like the subject of this post that engage in some non-trivial semantic reasoning. :)
dbaupp 10y ago
> But others point out that explicit lifetime annotation is not required to evaluate memory safety [3]. I think you've extrapolated a bit too much from that answer: the code still has to be semantically lifetime-correct, even if the annotations don't need to exist syntactically. Code that wasn't written with Rust-style lifetimes in mind (even if they're not literally written in the code) is unlikely to automatically satisfy the rules statically, so unless SaferCPlusPlus is using a custom compiler that runs Rust-like rules on the code and flags violations, I would expect a lot of such code is only dynamically correct. > [2] https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp.. https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp.... A few points: - what do you mean by rebindable and non-rebindable references? That is not terminology Rust uses at all, and so it isn't clear what this is referring to. - The restriction on multiple aliasing for mutable references is not just to avoid objects being deallocated, it avoids things like iterator invalidation and concurrency problems like data races.
- 10y ago