> It transliterates C into unsafe Rust. That's not too helpful.
From the author's perspective it is helpful. If the goal is to make an existing C project memory safe without sacrificing performance and memory efficiency, one way to do that is to rewrite it in (safe) Rust. An automated direct translation from C to (unsafe) Rust would result in a body of code that would not (completely) satisfy the borrow checker. But some significant portion of the code would, thus reducing the total work necessary to translate the project to safe Rust.
The thing is that you can satisfy the borrow checker by (manually) modifying the Rust code resulting from the automated translation, or, alternatively, you could modify the C code in such a way that the automated translation results in Rust code that satisfies the borrow checker. If you can manage to write C code that automatically translates to safe Rust, then the safety guarantees of the borrow checker also apply to the C code.
So the automatic translator can be used to apply Rust's borrow checker (and its safety guarantees) to C code. This would be one way to, for example, bring a degree of memory safety to embedded platforms that are not supported by Rust, but which do support C. Pretty sneaky, no? (Of course, some of Rust's memory safety is achieved through run-time checks rather than the borrow checker, so it doesn't completely solve the problem for C.)
But satisfying the borrow checker is still a lot of (mental) work, and as I've pointed out, there is an easier alternative. It would be much easier to write an automatic translator from C to SaferCPlusPlus[1]. And even for embedded platforms that don't support modern C++ (or at least its standard library), you can pull the same trick, as SaferCPlusPlus also uses a degree of static enforcement of memory safety (although not to quite the same degree as Rust's borrow checker.)
From the author's perspective it is helpful. If the goal is to make an existing C project memory safe without sacrificing performance and memory efficiency, one way to do that is to rewrite it in (safe) Rust. An automated direct translation from C to (unsafe) Rust would result in a body of code that would not (completely) satisfy the borrow checker. But some significant portion of the code would, thus reducing the total work necessary to translate the project to safe Rust.
The thing is that you can satisfy the borrow checker by (manually) modifying the Rust code resulting from the automated translation, or, alternatively, you could modify the C code in such a way that the automated translation results in Rust code that satisfies the borrow checker. If you can manage to write C code that automatically translates to safe Rust, then the safety guarantees of the borrow checker also apply to the C code.
So the automatic translator can be used to apply Rust's borrow checker (and its safety guarantees) to C code. This would be one way to, for example, bring a degree of memory safety to embedded platforms that are not supported by Rust, but which do support C. Pretty sneaky, no? (Of course, some of Rust's memory safety is achieved through run-time checks rather than the borrow checker, so it doesn't completely solve the problem for C.)
But satisfying the borrow checker is still a lot of (mental) work, and as I've pointed out, there is an easier alternative. It would be much easier to write an automatic translator from C to SaferCPlusPlus[1]. And even for embedded platforms that don't support modern C++ (or at least its standard library), you can pull the same trick, as SaferCPlusPlus also uses a degree of static enforcement of memory safety (although not to quite the same degree as Rust's borrow checker.)
[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus