DARPA project for automated translation from C to Rust (2024) • Hacker News Board

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

#91

Post by pizlonator » Thu, Oct 02, 2025, 12:31 AM UTC

woodruffw wrote: post #55

pizlonator wrote: post #31

(Sorry for talking about my personal project again y’all.) What I want folks to get out of the Fil-C thing is that the whole notion that C is a memory unsafe language and Rust (or any other language) being safer is a subtle thought error. The truth is: C as it is currently implemented is unsafe, and implementing it in a safe way is possible but we choose not because that would make it slower and use more memory . The…

> What I want folks to get out of the Fil-C thing is that the whole notion that C is a memory unsafe language and Rust (or any other language) being safer is a subtle thought error. I think what you’re doing with Fil-C is cool and interesting. But I think you’re talking past a large part of the “memory safety” audience with this framing: most people don’t want “memory safety” qua uncontrolled program termination, the…

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 you is static checking of a bunch of stuff and also memory safety. Fil-C gives you memory safety (and Fil-C’s memory safety goes further than Rust’s).

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

#92

Post by treyd » Thu, Oct 02, 2025, 12:32 AM UTC

sitzkrieg wrote: post #90

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…

> If I clone a Rust repo, it’s actually easier to compile, test, and run the code than any other language zig is very comparable, and much faster at doing so. zig also comes with a build system, libc and can compile c programs. its a better c compiler and build system than most, lol.

But Zig doesn't have the very sophisticated type system that Rust has. Nor does it, importantly to DARPA, have the memory safety that Rust does.

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

#93

Post by pizlonator » Thu, Oct 02, 2025, 12:35 AM UTC

AlotOfReading wrote: post #66

pizlonator wrote: post #56

Earlier quoted context omitted.

> Making C memory-safe doesn't make the semantics of all UB defined or appropriate. Fil-C largely gets rid of UB. There are exceptions left but they’re all fixable. The only reasons why C has UB are: - lack of memory safety (Fil-C fixes this) - policy (Fil-C mostly fixes this but there are still a small number of remaining issues, which I intend to fix). Fil-C is super comprehensive in how it fixes C. I bet it’s more…

It's on my free-time backlog to spend more time with Fil-C, so I'm not disagreeing from lack of interest. Most of annex-J is unrelated to memory safety. No, C has explicit UB because there wasn't a defined behavior that made sense to codify in the standards process. Signed overflow, invalid printf specifiers, and order of evaluation for example. I assume Fil-C doesn't fix things like uninitialized memory or division…

Fil-C absolutely does fix uninitialized memory.

It’s on my list to solve division. It’s easy to do and also not super important for the security angle that I’m addressing. But with doing precisely to provide clarity to these kinds of discussions.

I’ve mostly tackled signed overflow. I’ve fixed all the cases where signed overflow would let you bypass Fil-C’s own bounds checks. It’s not hard to fix the remaining cases.

In short: any remaining UB in Fil-C is just a bug to be fixed rather than a policy decision.

The reason why C has UB today is policy and memory safety.

Its a goal of Fil-C to address memory safety violations by panicking because:

- That’s the most secure outcome.

- That’s the most frantically compatible with existing C/C++ code, allowing me to do things like Pizlix (memory safety Linux userland)

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

#94

Post by treyd » Thu, Oct 02, 2025, 12:35 AM UTC

0x696C6961 wrote: post #70

AlotOfReading wrote: post #57

Earlier quoted context omitted.

It's not usually the standard library or dependencies that create the issues I've seen. The teams I work with producing Go tools (across multiple companies) invariably require carefully orchestrated dev environments that are nigh-unreproducible. It's 50/50 on whether I can actually build a random project first try without reading the instructions if CGO is involved, which seems to be all of them. My experience with r…

Rust projects which depend on C libs have very similar issues.

I haven't experienced this. Rust's build system allows you to automate most of the pain in building/bundling those dependencies, so it's just up to the builder to have the right headers (if they're not bundled). That makes it no worse than meson C/C++ builds.

In Go, it doesn't have any of that so it depends on the end builder of the binary to be aware of all the C dependencies and manually manage integrating the cgo configuration into their build process.

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

#95

Post by pizlonator » Thu, Oct 02, 2025, 12:37 AM UTC

adastra22 wrote: post #65

pizlonator wrote: post #40

Earlier quoted context omitted.

Definitely not. Then it wouldn’t be a C implementation. Fil-C is so compatible that I have a Linux userland compiled with it https://fil-c.org/pizlix Think of Fil-C as Java-ifying C an C++

I don’t see the relevance to this discussion then.

You’re confusing memory safety with Rust’s specific flavor of static checking.

Totally not the same thing.

Like, notice how DARPA is in no hurry to have folks rewrite Java or JavaScript in Rust. Why? Because even JavaScript is memory safe. It’s not achieving that with dynamic checking rather than static checking.

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

#96

Post by pizlonator » Thu, Oct 02, 2025, 12:38 AM UTC

adastra22 wrote: post #81

NobodyNada wrote: post #75

Earlier quoted context omitted.

The discussion is about a project for securing legacy code by machine-translating it to Rust. Fil-C is an alternative way to secure legacy code using a different C implementation. I think that's highly relevant to the discussion.

The kind of errors being protected against are totally different though.

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.

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

#97

Post by treyd » Thu, Oct 02, 2025, 12:40 AM UTC

jchw wrote: post #63

bangaladore wrote: post #11

One of, in my opinion, the largest problem with Rust is that they sought to solve two problems: 1. Memory / thread safety 2. They didn't like C/C++ And often times it feels like there is more focus on problem two than problem one. Quite a bit of idiomatic and safe (yes that does exist) C++ doesn't "translate" well to Rust without large amounts of rearchitecting. I'd focus more on converting C/C++ to languages nearing…

To be honest I don't buy it. The biggest problem with translating programs to Rust, IMO anyway, isn't actually dealing with the chasm between mentalities regarding programming language design. I don't disagree that Rust intentionally goes a different way in many regards; obviously it focuses on composition over inheritance, and takes more inspiration from ML. But still, that isn't really the problem. It really does c…

> Literally just not being able to easily and efficiently express interior mutability completely changes how you design both code and APIs.

The issue is that fundamentally interior mutability is hard to reason about. It requires a lot more temporal reasoning to make sense of and ensure the safety of. Leaning into the type system Rust has does make interior mutability harder when you have "temporally based" safety arguments. It's a lot easier to reason about correctness in the model Rust uses.

Have you looked at the godot-rust bindings? They've gone very far to make the Godot object system work well going between C++ Godot code and Rust. I would love to see that model adapted to Gtk.

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

#98

Post by brendank310 » Thu, Oct 02, 2025, 12:41 AM UTC

Past work in the area by the folks at Immunant (https://immunant.com/) that appears to be on-going https://github.com/immunant/c2rust. I think the project was also DARPA funded for a time.

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

#99

Post by treyd » Thu, Oct 02, 2025, 12:43 AM UTC

pizlonator wrote: post #17

adastra22 wrote: post #15

Earlier quoted context omitted.

Examples?

Doubly linked lists. Any cyclic data structure.

There are doubly-linked list libraries in Rust. They are safe and well-designed. It's rare for a project to actually need a doubly-linked list. When you need it, you should use those instead of reimplementing your own.

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

#100

Post by AnimalMuppet » Thu, Oct 02, 2025, 12:46 AM UTC

foota wrote: post #43

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…

This is a bizarre take to me, what do you want to do with classes that aren't supported by structs and traits? Imo the usability issues with rust arise from the borrow checker and associated complexity + restrictions on patterns, so I'm surprised that you're citing macros and classes.

Access control.

Here's a struct that maintains an invariant - say, that field a is less than field b. That invariant should be set when it is created.

You find a bug where a is greater than b. Where is the bug? With a struct, it can be anywhere in the code - any line that touches the struct. But with a (well designed) class, a and b are private, and so you only have to look at lines of code within the class. The surface area where the bug can be is much smaller.

The bigger the code base and the more well-used the class is, the more this matters.