HN Reader

Automatically translating C to unsafe Rust is pointless, the resultant code is harder to read and there's no improvement in understanding how to get the code maintainable and safe, that requires tons of manual work by someone with a deep understanding of the codebase.

Generally the Rust community as well don't seem to have an answer on how to do this incrementally. In business terms we have no idea how to do work slices with demonstrable value, so no way to keep this on track and cut losses if it becomes too much work. This also strongly indicates you're 'stuck' with Rust when you're done, maybe a better and less unidiomatic C++ killer comes later and sounds like you're either going to have to rewrite the whole thing or give up.

I'm definitely open to wisdom on this if anyone disagrees because it is valuable to me and probably most of the readers of this comment section.

In a way this is strange because there us a huuuge new area of vulnerabilities caused by LLMs writing code that DWARFS the read/write out of array bounds issues C has.

The other direction might be more interesting, in case rust drops in popularity in a couple of years, leaving behind a bunch of "let's rewrite in rust" efforts

I just upgraded my Ubuntu to the new version with Rust written Coreutils - this is insane

    % size /usr/bin/ls
       text    data     bss     dec     hex filename
    10086795  731540    2104 10820439  a51b57 /usr/bin/ls

    % ls -sh /usr/lib/cargo/bin/coreutils/ls
    11M /usr/lib/cargo/bin/coreutils/ls

    % du -sh /usr/bin
    1.5G /usr/bin

The key invention here would be to translate from idiomatic C to idiomatic - safe - Rust.

That also sounds exactly like the kind of invention that would make me fear for my job and claim AGI has all but arrived.

Just syntactically translating C code to mostly unsafe or non-idiomatic Rust seems like a pretty pointless excercise?

The article doesn't address the hard problem of figuring out array sizes. There's some work going on as part of the DARPA TRACTOR program to work on that. This area, of course, is the usual cause of buffer overflows.

The goal is to convert C pointers to Rust arrays, pointer arithmetic to Rust slices, and array allocations to Vec initialization. The hard problem is figuring out the sizes of arrays, which is going to require global analysis down the call chain.

If you're going to publish papers on this, please address that problem.

The code I've seen that was autotranslated from C to Rust has an absolutely hopeless number of unsafe statements.

You're better off using Fil-C.