Autotranslations from C will be seen as what they are, a transliteration from a less safe language with exactly the same bugs as the preexisting codebase. You could think of the case of calling a COM library that has a leak or a OOB error, I wouldn't blame the language doing the calling for the bug.
Having said that, these translations are still useful as a starting point, not a destination. Think of a case where the external C API is retained, but all the innards are gradually converted to a more idiomatic codebase.
I disagree on that. Rust also took a credibility hit for people advertising exactly the opposite: To rewrite things from scratch. While that approach certainly helps with getting idiomatic code right from the start, years of feature development will get lost, and the chances for introducing non memory related bugs are still there.
The ability to transfer a project to Rust in 1 step, and then to gradually improve it seems like a big plus to me. Of course it would not be great if projects are just auto-translated and then kept that way. But I don't think that is the intention of most authors who do that.
* Replace some extern "C" includes with more idiomatic uses. Pretty straightforward find/replace-all usually does the trick. * Pick a utility, like cat or touch, and work on translating it into safer, more idiomatic rust. There are plenty of unsafes lying around that you can tackle!
(With apologies to to Aladdin.)
I don't see any LICENSE or COPYING files in the repo.
int COMMAND_main(int argc, char **argv)
and that it's compilable as a library already, I wonder if it would make more sense to use bindgen or the like to start with the actual busybox C code, but with a (trivial) Rust main function. You'd have the current busybox source compiling an ever-smaller library, and a Rust lib next to it. Then move things over to the Rust side one command at a time.Yes, literally. But figuratively, No, because you used the C as a higher order definition language and did translation not re-implementation.
So this might (in some cases) be bug for bug compatible (a good thing?) if the bug is a logic bug, not a C boundary error or a type cast effect or something not strictly defined. It isn't an "independently implemented suite" if you wanted to e.g. use it for conformance testing to a spec.
It's somewhat impressive that c2rust is can translate so much code, but without following it up with refactoring into more idiomatic Rust (which is a lot of work), this is merely replacing gcc with rustc.
https://git.busybox.net/busybox/tree/networking/httpd.c
Shame the rustybox version strips all the comments:
https://github.com/samuela/rustybox/blob/master/networking/h...
I just wish that all Rust implementations would include a "Git" or "Docker containers" section as a stepping stone in the right direction for other projects.