Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DARPA project for automated translation from C to Rust (2024)

darpa.mil

Post reply on HN
Print view View original

141–150 of 194 posts

Re: DARPA project for automated translation from C to Rust (2024)

#141

Post by bangaladore »

kibwen wrote: post #137
bangaladore wrote: post #53

Earlier quoted context omitted.

C/C++ is the "default" language they are/were trying to replace with Rust. So I think it's fair to point out that Rust made design decisions explicitly contrary to design decisions of C/C++ style languages even though Rust is meant to replace it. That's going to (and does cause) problems.

> design decisions explicitly contrary to design decisions of C/C++ style languages even though Rust is meant to replace it Yes, but that doesn't have to do with whether they "like" C++ or not. What they "liked" is a programming model that could possibly be theoretically proven safe by any sort of tractable static analysis, and that inevitably means making decisions contrary to C/C++. Achieving their design goals was…

You are confusing problem 1 (memory / thread safety) with problem 2 (being distinct from C/C++). I'm not here to argue about changes made that are necessary to solve problem 1, but I'm also not here to pretend that all the differences Rust has compared to a C-style language like C/C++/C# is largely due to supporting memory / thread safety.

Re: DARPA project for automated translation from C to Rust (2024)

#142

Post by woodruffw »

pizlonator wrote: post #115
scottlamb wrote: post #101

Earlier quoted context omitted.

> The argument for using Rust instead of a memory safe implementation of C is all about performance. And that’s not a bad argument! But we should be honest about it. I think it might also be that people mostly consider languages from the perspective of what they'd write a greenfield codebase in. And if I'm gonna pay the GC cost, I'd much rather work with language/library body that doesn't have tons of ownership idiom…

I think what you’re saying is true for the kind of software where it isn’t just greenfield but also doesn’t have to make deep use of preexisting system dependencies. Like, say you’re writing a port daemon. Then your argument holds! And that’s admittedly a big category since it includes databases, application servers, and a lot of other stuff. But say you’re writing an app that talks to systemd and your desktop shell…

> Now you might say, why not rewrite all the deps in Go or Rust? The funny thing about that is you sort of can’t do that today since neither of those languages has dynamic linking.

I don’t know about Go, but that’s certainly not true for Rust. Dynamic linking is the norm in Rust; you can run `ldd` on any stock-built binary to see that it dynamically links to glibc (or libSystem or similar).

(It’s also common for Rust libraries to be distributed as shared objects with C APIs/ABIs — to my understanding, this is how virtually every incremental adopter of Rust has chosen to adopt it.)

Re: DARPA project for automated translation from C to Rust (2024)

#143

Post by Animats »

This is C to Rust, not C++ to Rust. That's important.

DARPA was willing to award multiple contracts, but the only one awarded is to a group from several universities. [1]

"The team’s approach, Formally-Verified Compositional Lifting of C to Rust (which forms the acronym ForCLift, pronounced “forklift”), uses Verified Lifting, which combines formal methods and program analysis with AI techniques such as Large Language Models, so as to create accurate translations of complex C code into safe, idiomatic Rust. The approach seeks to enable formal verification of the translated code while also preserving performance-critical behavior."

This involves something called "Verified Lifting."[2] "Metalift uses verified lifting to search for possible candidate programs in the target language that the given input can be translated to." So it's looking for matching idioms in the target language and using proof techniques to check that they are equivalent. Going uphill in abstraction automatically is rare. This will definitely be interesting. It's essential to good translation.

The old C2Rust is all downhill. What comes out of C2Rust are huge numbers of calls to functions that exactly emulate C semantics, bugs and all. I tried it once, on a buggy JPEG 2000 decoder. The test case which caused a segfault in the C version also caused a segfault in the unsafe Rust version. At least it generates compatible code.

[1] https://www.cs.wisc.edu/2025/07/15/translating-legacy-code-f...

[2] https://metalift.pages.dev/

Re: DARPA project for automated translation from C to Rust (2024)

#144

Post by adastra22 »

kibwen wrote: post #138
adastra22 wrote: post #62

Earlier quoted context omitted.

At the time that Rist was created, C/C++ and Java were pretty much the only industry standard languages.

No, even by 2010, Javascript, PHP, and Python would have all already surpassed C and C++ by number of professional programmers in industry.

None of those are systems languages.

Re: DARPA project for automated translation from C to Rust (2024)

#145

Post by adastra22 »

pizlonator wrote: post #106
JoshTriplett wrote: post #82

Earlier quoted context omitted.

(Note that I edited my comment for clarity since the original reply. My original comment just said "reference counting".)

The key part I agree with most in your edited comment is that unsafe raw pointers are the easiest way to deal with cycles. I think this is key. RC pointers don’t give you the ability to say: ok, I now know that this subset of the graph is dead because reasons so delete it. In RC, you’d have to walk the graph to break cycles. That’s a rather important difference from how you’d manage a cyclic data structure in C, C++,…

> RC pointers don’t give you the ability to say: ok, I now know that this subset of the graph is dead because reasons so delete it.

That’s exactly what weak references do.

Re: DARPA project for automated translation from C to Rust (2024)

#146

Post by pizlonator »

woodruffw wrote: post #139
pizlonator wrote: post #91

Earlier quoted context omitted.

I’m not inventing a definition for memory safety out of thin air, so I think there’s just a tendency to conflate Rust’s static checking with memory safety. Rust’s most important safety mechanism is panicking on out of bounds access. OOBA’s are the thing that attackers most want to do, and Rust, Fil-C, and almost all of the other memory safe languages solve that with runtime checking. In short, I’d say what Rust gives…

> OOBA’s are the thing that attackers most want to do, and Rust, Fil-C, and almost all of the other memory safe languages solve that with runtime checking. On browsers and other high-performance codebases? I would have guessed UAFs and type confusions would be higher on the attacker priority queue for the last 15 years. Rust prevents those statically.

My data comes from OSes as a whole not just from browsers or high performance codebases.

Re: DARPA project for automated translation from C to Rust (2024)

#147

Post by pizlonator »

woodruffw wrote: post #142
pizlonator wrote: post #115

Earlier quoted context omitted.

I think what you’re saying is true for the kind of software where it isn’t just greenfield but also doesn’t have to make deep use of preexisting system dependencies. Like, say you’re writing a port daemon. Then your argument holds! And that’s admittedly a big category since it includes databases, application servers, and a lot of other stuff. But say you’re writing an app that talks to systemd and your desktop shell…

> Now you might say, why not rewrite all the deps in Go or Rust? The funny thing about that is you sort of can’t do that today since neither of those languages has dynamic linking. I don’t know about Go, but that’s certainly not true for Rust. Dynamic linking is the norm in Rust; you can run `ldd` on any stock-built binary to see that it dynamically links to glibc (or libSystem or similar). (It’s also common for Rust…

When you do that, the ABI boundary around your shared library is unsafe.

So if you rebuilt userland with Rust and had the same layout of shared libraries then you’d have a massive amount of unsafe code

Re: DARPA project for automated translation from C to Rust (2024)

#148

Post by pizlonator »

adastra22 wrote: post #124
pizlonator wrote: post #96

Earlier quoted context omitted.

Fil-C protects against a superset of the errors that Rust protects against. It just does it dynamically. And more comprehensively. There’s no `unsafe` statement in Fil-C. There’s no need for it since dynamic checking is vastly more precise.

Dynamic/runtime checks (and crashes) are VERY different from compile time checks though. Many applications, and especially those that DARPA are focused on, care about ahead-of-time guarantees that code will work correctly, and runtime panic is actually the worst possible failure mode. Think of flight control software, for example.

This DARPA doc isn’t about flight software.

Rust uses runtime checking for array access bounds, which are the most common kind of memory safety vulnerability.

Re: DARPA project for automated translation from C to Rust (2024)

#149

Post by AbuAssar »

IceHegel wrote: post #41

I don’t think Rust syntax and patterns (no classes) are especially elegant for many tasks. I can’t express the behavior of a system as cleanly in Rust as TypeScript, C#, go or Python. I know that’s not what it was designed for, but a guy can dream. But what Rust has is the best tooling bar none(cargo, build system, compile time checks, ease of first use). The tooling is actually more important than the borrow checker…

> It avoided the fragmentation of JS/TS (npm, yarn, pnpm, bun, deno)

just use npm, the others are just more options, thersr is no "fragmentation"

Post reply on HN