DARPA is funding this. Good.<p>They haven't reached inter-procedural static analysis yet, which means they can't solve the big problem: how big is an array? Most of the troubles in C come from that.
Whoever creates the array knows how big it is. Everybody else is guessing.<p>A bit of machine learning might help here. If you see<p><pre><code> void dosomethingwitharray(int arr[], size_t n) {}
</code></pre>
a good conjecture is that <i>n</i> is the length of <i>arr</i>. So, the question is, if
this is translated to<p><pre><code> fn dosomethingwitharray(arr: &[i64]) {}
</code></pre>
does it break anything? Both caller and callee have to be analyzed. The C caller
has the constraint<p><pre><code> assert_eq!(arr.len(), n);
</code></pre>
That's a proof goal. If a simple SMT-type prover can prove that true., then the call can be simplified to just use an ordinary Rust slice. If not, conversion to Rust has to drop to those ugly C pointer forms, preferably with a comment inserted. So you need something that makes good guesses, which is a large language model kind of thing, and something which checks them, which is a formalism kind of thing.<p>The process can be assisted by putting asserts in the original C, as checks on the C and hints to the conversion process. That's probably the cleanest way to provide human assistance.<p>I've wanted this for conversion of OpenJPEG code to Rust. That's a tangle of code doing wavelet transforms, with long blocks of touchy subscripting and arithmetic, plus encoders and decoders for an overly complex binary format containing offsets and lengths. Someone recently ran it through c2rust. The unsafe Rust code works. It's compatible with the original C - it segfaults for the same test cases which cause the C code to segfault. This is why a naive transpiler isn't too helpful.<p>(The date at the bottom of the article is 2022-06-13. Has there been further progress?)
I used c2rust to start rewriting OpenJpeg into Rust code [0].<p>It was easy to get the Rust code compiled and working as a drop-in-replacement for the C Library. This has been a big help with refactoring the unsafe Rust code into safe Rust (manual work). OpenJpeg has a great testsuite that has allowed testing that each refactor step doesn't add new bugs (has happened at least 3 times).<p>The original run of c2rust generated 96,842 lines of Rust code (about 1 year ago), now it is down to 46,873 lines code. A lot of the extra 50k lines of code were from C macros that got expanded and from constant lookup tables (C code had 10-30 values per line, Rust 1 value 1 line).<p>For anyone looking to use c2rust to port C code to Rust, I recommend the following:<p><pre><code> 1. Setup some automated testing if it doesn't exist already.
2. Do refactoring in small amounts, run the tests and commit the changes before doing more refactoring.
3. Use "search/replace" tools (`sed`) to help with rewriting common patterns. Make sure to follow #2 when doing this.
4. Don't re-organize the code until after most of the unsafe code has been rewritten. This will allow easier side-by-side comparison with the original C code.
5. c2rust expands macros and constants from `#define`. Being able to do side-by-side comparison of the C code will help with adding constants back in and removing expanded code with Rust macros or just normal Rust functions.
</code></pre>
[0] <a href="https://github.com/Neopallium/openjpeg/tree/master/openjp2-rs">https://github.com/Neopallium/openjpeg/tree/master/openjp2-r...</a>
I took the insertion_sort impl from the bottom of the post and asked gpt4 to rewrite it into idiomatic Rust:<p><pre><code> pub fn insertion_sort(n: i32, p: &mut [i32]) {
for i in 1..n as usize {
let tmp = p[i];
let mut j = i;
while j > 0 && p[j - 1] > tmp {
p[j] = p[j - 1];
j -= 1;
}
p[j] = tmp;
}
}
fn main() {
let mut arr1: [i32; 3] = [1, 3, 2];
insertion_sort(3, &mut arr1);
// …
}
</code></pre>
I guess if this actually works, we can translate massive amounts of internal C libraries into human readable Rust... good stuff.<p>(funnily enough, passing in the "original" code without the `unsafe extern "C"` part makes it produce the exact same output as the above)
Has anyone put this to serious use? I played around with it at some point when it was fairly new and at that time I was able to transpile the C into Rust just fine, but that didn't help me much. The idea was to be able to use the Rust toolchain to better understand the code, but the resulting Rust code was even less understandable, and also much harder to refactor. In this case I wasn't attempting a rewrite per se, just trying to understand a C codebase plagued with memory safety issues. Quickly gave up on this avenue at that point and just started carefully refactoring the C to make the bugs easier to shake out.<p>Would love to see a technical write up of someone outside Immunant using this on a real world codebase for whatever purpose.
C2rust is really cool, but if you're familiar with writing rust and implement even a trivial C function in there it produces something absolutely terrifying. I really enjoy rust and pray I don't find myself working in a code base someone just ran c2rust against.
Since this is DARPA, this shows they are interested in rust, which mean we will probably have strong toolchain certifications coming up eventually, making rust even more fall in the category of "the language you want to use for serious stuff".
This seems like an interesting project to bridge the "boil the ocean" approach of rewriting in Rust wholesale.<p>(For anyone else who found it slightly difficult to read, you can remove the added 0.06em `letter-spacing` using your browser's developer tools.)
I'm very excited at the possibilities for C2Rust! Dynamic analysis to fill in the gaps of static analysis makes a lot of sense. I've wanted something similar for inferring TypeScript types via runtime analysis (would not be surprised if it exists already).<p>I could see a really compelling use case in cross-compilation where you compile your C code to Rust, then use a Rust toolchain to cross compile. Or avoiding interop as well.
Do no know this particular tool but some automated language to language transpilers I saw produce the code one would not be able to comprehend never mind edit if the need comes.
I wish they revive their refactoring tool - it was abandoned during the toolchain upgrade. Without the tool, converting the code becomes much more tedious.