For the author:<p>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.<p>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).<p>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.<p>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.<p>[1] <a href="https://github.com/duneroadrunner/SaferCPlusPlus" rel="nofollow">https://github.com/duneroadrunner/SaferCPlusPlus</a><p>[2] <a href="https://github.com/duneroadrunner/SaferCPlusPlus#safercplusplus-versus-rust" rel="nofollow">https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp...</a><p>[3] <a href="http://stackoverflow.com/questions/31609137/why-are-explicit-lifetimes-needed-in-rust#31612025" rel="nofollow">http://stackoverflow.com/questions/31609137/why-are-explicit...</a>