I've tried that thing. The Rust that comes out is terrible. It converts C into a set of Rust function calls which explicitly emulate C semantics by manipulating raw pointers. It doesn't even convert C arrays to a Vec. It's a brute-force transliteration, not a translation.

I and someone else ran this on a JPEG 2000 decoder that sometimes crashed with a bad memory reference. The Rust version crashed with the same bad memory reference. It's bug-compatible.

What comes out is totally unreadable and much bigger than the original C code. Manual "refactoring" of that output is hopeless.

Any automatic translation is bug-compatible with the original. Did you expect it to divine some requirements?

It still leave you with Rust code that you can improve piecewise. The only question is if something like it is better than FFI calling the C code.

> Any automatic translation is bug-compatible with the original. Did you expect it to divine some requirements?

That would be useless when translating C to Rust. Yes, I would expect the tool to point out the flaws in the original memory handling and only translate the corrected code. This is far from easy, since some information (intent) is missing, but a good coder could do it on decent codebases. The question is, can an automated tool do it too? We'll see.

It doesn't make sense to convert a C array to a Vec, the Vec type is a growable array but the C array isn't growable. It makes sense to convert to Rust's array type, which has a fixed size, and we realise there's a problem at API boundaries because C's arrays decay to pointers, so the moment we touch an API boundary all safety is destroyed.

Depends on how the array is created. If it comes from "malloc" or C++ "new", it may need to be created as a "Vec".

Firstly, that's not an array. C has actual arrays, even though they decay to pointers at API edges and what you've made with malloc is not an array. I'll disregard C++ new and new[]

But also, it's definitely not a growable array. Box::new_uninit_slice makes the thing you've got here, a heap allocation of some specific size, which doesn't magically grow (or shrink) and isn't initialized yet.

> I ran this on a JPEG 2000 decoder that sometimes crashed with a bad memory reference. The Rust version crashed with the same bad memory reference. It's bug-compatible.

Of course it is. The README says it generates unsafe rust in the first paragraph, what did you expect?

I think it's a really fascinating experiment, and IMHO it's pretty remarkable what it can do. This is an incredibly difficult problem after all...

It seems easy (relatively speaking) to directly translate C to Rust if you're allowed to use unsafe and don't make an effort to actually verify the soundness of the code. But if you need to verify the soundness and fix bugs while translating it? That's really hard, and that's what it sounds like what TRACTOR wants to do.

Using "unsafe" doesn't automatically make Rust useless, of course, but the example on the c2rust website itself doesn't make any effort to verify its usage of unsafe (you can easily read memory out of bounds just by changing "n" to "n + 1" in the example loop). Sadly, that is a much, much harder problem to solve even for fairly basic C programs.

Eh, if c2rust "seems fairly easy" to you, I can pretty much guarantee you don't appreciate the complexity involved. Just take a look at the commit log...

Their work was also previously sponsored by DARPA, though I do not know if it was under this program or something else.

It must have been a different program, as this one hasn’t started yet, but perhaps by another program by the same program manager.

As I mentioned elsewhere (https://news.ycombinator.com/item?id=41113257), that tool is pretty much useless unless you have some checkbox that says "no C code allowed anywhere". It's not even a feasible starting point for refactoring because the code is so far from idiomatic Rust.