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

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

#191

Post by junon » Fri, Oct 03, 2025, 9:44 AM UTC

voidmain wrote: post #189

junon wrote: post #177

Earlier quoted context omitted.

I guess I don't see how making inherently incorrect C code "safe" by sanitizing something it shouldn't be doing anyway is actually improving the C code.

The key thing that memory safety provides is local reasoning. You can look at some important piece of code and conclude that it does the right thing, even if there are a million other lines of code somewhere else. UB makes this impossible; no matter how carefully you review dont_launch_missiles() it might launch the missiles due to an integer overflow in totally unrelated code in the same process.

I agree with you, but this feels more of "fixing" inherently unsafe code in the same way we "fixed" the elephant's foot in Chernobyl by covering it with a giant roof. It doesn't actually fix the problem, just lessens and prolongs it.

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

#192

Post by tialaramex » Fri, Oct 03, 2025, 10:47 AM UTC

junon wrote: post #191

voidmain wrote: post #189

Earlier quoted context omitted.

The key thing that memory safety provides is local reasoning. You can look at some important piece of code and conclude that it does the right thing, even if there are a million other lines of code somewhere else. UB makes this impossible; no matter how carefully you review dont_launch_missiles() it might launch the missiles due to an integer overflow in totally unrelated code in the same process.

I agree with you, but this feels more of "fixing" inherently unsafe code in the same way we "fixed" the elephant's foot in Chernobyl by covering it with a giant roof. It doesn't actually fix the problem, just lessens and prolongs it.

Yes the resemblance to the sarcophagus is I suppose warranted. The best of bad options.

The assumption in Fil-C is that you can't or won't rewrite. So a modified C compiler which rejects the uninitialized variable (as Rust would) is not acceptable because now what? We were supposed to make the existing C program memory safe, not reject it, anybody could write a "compiler" which rejects the C programs as unsafe.

This is the same assumption C++ had. C++ 26 lands "Erroneous Behaviour" for this purpose. Previously if you write `int x; foo(x);` that's Undefined Behaviour in C++ just like C, game over, anything might happen if this executes.

In C++ 26 `int x; foo(x);` is Erroneous but not Undefined. It might tell you (perhaps at runtime) that you forgot to initialize x, because doing so is an error - but if it presses on it will behave like `int x = SOMETHING; foo(x)` where SOMETHING was chosen by your compiler and implemented exactly the way you'd expect, by quietly initializing your uninitialized variable.

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

#193

Post by Ygg2 » Fri, Oct 03, 2025, 11:11 AM UTC

array_key_first wrote: post #184

Ygg2 wrote: post #29

Earlier quoted context omitted.

> They didn't like C/C++ Riiiight. You do realize they made syntax similar to C/C++ on purpose to ease Mozilla's C/C++ programmers into it. It's not that they didn't like it; it's that C/C++ is about as disinterested in memory/thread safety as you can get. It's been what, ten years since Rust became 1.0? And the safety needle of C++ hasn't budged a femtometer. > Quite a bit of idiomatic and safe (yes that does exist)…

C++ is much more safe than C and has numerous safety contracts that are impossible to represent in C. Its always weird when C and C++ are thrown together. Barne has talked about it, but one of the primary reasons he created C++ was to address safety issues in C. And he's talked about this since the early 90s. Like access modifiers and private by default. Something we take for granted now, but something which is impos…

> C++ is much more safe than C

The issue Mozilla faced wasn't that it wasn't safer than C. It's that it was not safe enough for their needs. A chainsaw is safer than a saw blade; you still don't want to trim your beard with it.

And the C++ working group, to this day, hasn't even moved one inch to accommodate those needs. As another commenter noted, they added a feature for C++26 that Rust abandoned circa 2019.

They couldn't multithread the components like compositor and renderer as much as they would have liked, even with all the caveats.

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

#194

Post by array_key_first » Fri, Oct 03, 2025, 11:51 PM UTC

Ygg2 wrote: post #193

array_key_first wrote: post #184

Earlier quoted context omitted.

C++ is much more safe than C and has numerous safety contracts that are impossible to represent in C. Its always weird when C and C++ are thrown together. Barne has talked about it, but one of the primary reasons he created C++ was to address safety issues in C. And he's talked about this since the early 90s. Like access modifiers and private by default. Something we take for granted now, but something which is impos…

> C++ is much more safe than C The issue Mozilla faced wasn't that it wasn't safer than C. It's that it was not safe enough for their needs. A chainsaw is safer than a saw blade; you still don't want to trim your beard with it. And the C++ working group, to this day, hasn't even moved one inch to accommodate those needs. As another commenter noted, they added a feature for C++26 that Rust abandoned circa 2019. They c…

> The issue Mozilla faced wasn't that it wasn't safer than C. It's that it was not safe enough for their needs.

I would agree with this for most use cases. My main qualm is lumping together C and C++.

It's like lumping together Rust and JS, because they're both memory safe. But Rust is WAY more safe. JS is, overall, an extremely footgunny language.

In my view, the jump from C to C++ is about the same as the jump from Rust to JS, potentially even bigger.