Live data from Hacker News

Translating All C to Rust (TRACTOR)

darpa.mil

361–370 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#361
post #346

I'm really surprised this can work at all in any automated way. You can't just make a line-by-line transcription of a typical c program into rust. Pointers and aliasing are ubiquitous in c programs, concepts that rust explicitly prevents. You have to rethink many typical constructs at a high level to rewrite a c program in rust, unless you wrap the whole thing in "unsafe."

For a naive newcomer - could you go line by line, wrap the whole thing in “unsafe”, compile to an identical binary, and then slowly peel away the “unsafe” while continuing to validate equivalence? That would at least get you to as much rust as possible, and then let engineers tackle rethinking just those concepts.

Converting C to legal (unsafe) Rust is quite possible; there is indeed already a tool that does this (https://github.com/immunant/c2rust).

The problem you run into is that the conversion is so pedantically correct that the resulting code is useless. The result retains all of the problems that the C code has, and is so far from idiomatic Rust that it's easier to toss the code and start from scratch. Progressive lifting on unsafe Rust to safe Rust is a very difficult order, and the tool I mentioned had a tool to do that... which is now abandoned and unmaintained.

At the end of the day, the chief issue with converting to safe Rust is not just that you have to copy semantics over, but you also have to recover a lot of high-level preconditions. Turning pointers into slices is perhaps the easiest task of the lot; given the very strict mutability rules in Rust, you also have to work out when and where to insert things like Cell or Rc or Mutex or what have you, as well as building out lifetime analysis. And chances are the original code doesn't get all these rules right, which is why there are bugs in the first place.

Solving that problem is the goal of this DARPA proposal, or perhaps more accurately, determining how feasible it is to solve that problem automatically. Personally, I think the better answer is to have a semi-automated approach, where users provide as input the final Rust struct layouts (and possibly parts of the API, to fix lifetime issues), and the tool automates the drudgery of getting the same logic ported to that mapping.

Re: Translating All C to Rust (TRACTOR)

#362
post #359

Earlier quoted context omitted.

Line by line is infeasible, which is precisely why you need to use AI to make larger semantic inferences. You also don't have to one-shot translate everything. One of the valuable things about the Rust compiler is it gives lots of specific information that you can feed back into an LLM to iterate. I've been working on similar problems for my startup (grit.io) and think C -> Rust is definitely tractable in the near te…

What about convert to AST then ask the AI to convert to Rust. Would that work?

That’s probably the rout they would take, but the C AST won’t have ownership attributes. You‘d have to discover those yourself.

ASTs also don’t have much info on threading (that’s more or less limited to “the program starts a thread with entry point foo at some time”, “Foo waits for another thread to finish”)

Re: Translating All C to Rust (TRACTOR)

#363
I program in C++ and am very happy to do so. Modern C++ is very safe and actually fun to program in. It gives me enormous expressivity, extraordinary performance and safety when I need it. I'm not building space shuttles, I'm building 3D experiences, so I'm not terribly concerned about crashes. But even for me, I've not run into a memory corruption bug in recent memory (10-15 years.)

Bash C/C++ all you want. I'm happy to keep using it to my advantage.

Re: Translating All C to Rust (TRACTOR)

#364

> Those involved with the oversight of C and C++ have pushed back, arguing that proper adherence to ISO standards and diligent application of testing tools can achieve comparable results without reinventing everything in Rust. If you stick to extremely stringent coding practices and incorporate third party static verification tools that require riddling your code with proprietary situations, then sure, you can achiev…

It's quite hilarious to see the push back rust gets by the c/c++ community. Obviously their decades of hard work and experience to work with those languages are overriding their reasoning circuits. Who in their right mind would defend a language that has such major and obvious design flaws if a genuine alternative is there.

Re: Translating All C to Rust (TRACTOR)

#365
If we have smart AIs to write code, find bugs, and write tests - doesn’t that mean we can ditch the “safe” languages and go back to C?

Thats mostly a joke. But AI-hardened-C seems like it could be much better than current-human-only-C.

Re: Translating All C to Rust (TRACTOR)

#366
post #346

Earlier quoted context omitted.

For a naive newcomer - could you go line by line, wrap the whole thing in “unsafe”, compile to an identical binary, and then slowly peel away the “unsafe” while continuing to validate equivalence? That would at least get you to as much rust as possible, and then let engineers tackle rethinking just those concepts.

Converting C to legal (unsafe) Rust is quite possible; there is indeed already a tool that does this ( https://github.com/immunant/c2rust ). The problem you run into is that the conversion is so pedantically correct that the resulting code is useless. The result retains all of the problems that the C code has, and is so far from idiomatic Rust that it's easier to toss the code and start from scratch. Progressive lift…

Right. Used c2rust once. Been there, done that. The Rust code that comes out is awful. Does the same thing as the C code, bugs and all. You don't get Rust subscript check errors, you get segfaults from unsafe Rust code. What comes out is hopeless for manual "refactoring".

The hardest part may be Rust's affine type rules. Reference use in Rust is totally different than pointers in C/C++. Object parenting relationships are hard to express in Rust.

Re: Translating All C to Rust (TRACTOR)

#367

I program in C++ and am very happy to do so. Modern C++ is very safe and actually fun to program in. It gives me enormous expressivity, extraordinary performance and safety when I need it. I'm not building space shuttles, I'm building 3D experiences, so I'm not terribly concerned about crashes. But even for me, I've not run into a memory corruption bug in recent memory (10-15 years.) Bash C/C++ all you want. I'm happ…

What is the learning curve for newbies to avoid critical segfaults? If you still have to walk a tightrope to get code across the board, wouldn't all benefit from a plankway with guardrails instead?

I'm not dissing C or C++ in any way. I've used it. But I recognize there are some major footguns that aren't easy to avoid, causing a much longer learning curve than necessary to get things built. Rust at least seems determined to address them, good or bad!

Re: Translating All C to Rust (TRACTOR)

#368
My experience of AI as a coding assistant:

for Python - awesome

for golang - awesome

for JavaScript - awesome

for Zig - not awesome, AI doesn't get it, maybe training data set too small

for Rust - terrible - AI really doesn't get how it works, especially the hard bits

Re: Translating All C to Rust (TRACTOR)

#369

> Those involved with the oversight of C and C++ have pushed back, arguing that proper adherence to ISO standards and diligent application of testing tools can achieve comparable results without reinventing everything in Rust. If you stick to extremely stringent coding practices and incorporate third party static verification tools that require riddling your code with proprietary situations, then sure, you can achiev…

proprietary annotations*

Sorry, autocorrect, I typed this on my phone.

Re: Translating All C to Rust (TRACTOR)

#370
post #367

I program in C++ and am very happy to do so. Modern C++ is very safe and actually fun to program in. It gives me enormous expressivity, extraordinary performance and safety when I need it. I'm not building space shuttles, I'm building 3D experiences, so I'm not terribly concerned about crashes. But even for me, I've not run into a memory corruption bug in recent memory (10-15 years.) Bash C/C++ all you want. I'm happ…

What is the learning curve for newbies to avoid critical segfaults? If you still have to walk a tightrope to get code across the board, wouldn't all benefit from a plankway with guardrails instead? I'm not dissing C or C++ in any way. I've used it. But I recognize there are some major footguns that aren't easy to avoid, causing a much longer learning curve than necessary to get things built. Rust at least seems deter…

To a first approximation, avoid using raw pointers. They should almost never be needed in application code. Use C++'s standard library facilities for smart pointers and containers instead. They are masterpieces of engineering, and work extremely well.
Post reply on HN