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

161–170 of 194 posts

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

#161

Post by littlestymaar »

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…

> Quite a bit of idiomatic and safe (yes that does exist) C++ doesn't "translate" well to Rust without large amounts of rearchitecting.

How? If you're writing modern safe-ish (still very unsafe though) C++, then you're going to be avoiding shared mutability and using lots of smart pointers which translate straightforwardly to Rust.

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

#162

Post by tialaramex »

junon wrote: post #153
pizlonator wrote: post #93

Earlier quoted context omitted.

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.…

How does Fil-C "fix" uninitialized memory?

I assume under the same "memory safety" rationale it just zeroes the RAM. That's "safe" and compatible with C.

In a good language this mistake is caught at compile time, like in Rust, the compiler says "Hey, I don't see how this variable is initialized before use" and you slap your forehead and fix it. But zeroing everything is technically safe.

For the Casey "hand made" Muratori type zeroing might even seem like a better idea. It's cheap, it means now your code compiles and executes, who cares about correctness?

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

#163

Post by woodruffw »

pizlonator wrote: post #147
woodruffw wrote: post #142

Earlier quoted context omitted.

> 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

> 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

Sort of, but I think that’s misleading; you’d have a massive amount of safe code, scaffolded with unsafe ABI boundaries. That’s a problem, but it’s not really the same kind of attacker or fault surface as unsafe code in the libraries themselves.

It’s also a wholly solvable problem in the sense that Rust could define a stable non-C ABI. There just hasn’t been an extraordinary need for that yet, since most people who want to build Rust code into shared objects do want a C ABI.

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

#164

Post by pjmlp »

pornel wrote: post #104
woodruffw wrote: post #55

Earlier quoted context omitted.

> 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…

Another aspect is that the majority of projects that keep using C, do it specifically to maximize performance or low-level control (codecs, game engines, drivers, kernels, embedded). For such projects, a GC runtime goes against the reason why they used C in the first place. Rust can replace C where Fil-C can't. A technically memory-safe C with overhead is not that groundbreaking. It has already been possible with san…

Many project do keep using C out of cultural and human reasons as well, they could have long written in a memory safe language, but goes against their world view, even when proven otherwise.

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

#165

Post by pjmlp »

tialaramex wrote: post #160
jandrewrogers wrote: post #130

Earlier quoted context omitted.

Don’t underestimate Zig’s comptime or modern C++’s constexpr. You can use these to prove things about the program at compile-time far beyond the type system. In recent versions of C++, the scope of code that is compile-time verifiable is quite large, nothing like when it was first introduced 15 years ago. This has limited (but not zero) applicability to memory safety but it has a lot of applicability to many other cl…

C++ constexpr is a nasty trap. Because after all it says right on the tin that we're getting a constant expression right? So it's as powerful as Rust's const right? Nope - of course the usual suspects insisted they needed a way to write non-constant expressions and have that somehow "work" anyway. So whereas a const function in Rust genuinely is constant, a constexpr function in C++ might not be, and we only find out…

True, however I would expect that anyone that knows constexpr is also aware of constinit, consteval and static constexpr.

Does it suck instead of having a single mechanism?

Yes, but the tools are there to actually enforce it at compile time.

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

#166

Post by woodruffw »

blub wrote: post #158
woodruffw wrote: post #55

Earlier quoted context omitted.

> 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…

“ most people really want to be able to write code that doesn’t crash at all because of expressive limits in C’s semantics. “Memory safety” is a convenient term of art for this.” Rust doesn’t rely only on compile-time checks, so I find your claim dubious. Actually, the dynamic checks done by Rust are presented as useful features in themselves. The memory safety audience and most people seem like arbitrary groups defi…

I didn’t say it relies only on compile time checks. Where are you getting that from?

The point about expressive semantics is that you can foreclose on vulnerabilities statically, not that everything becomes a static check. That’s why I mentioned UAFs and type confusions in the adjacent response below.

> Taking standard C code and achieving the above would be amazing and much more useful than rewriting something in Rust.

As others have pointed out, you can’t do this without biting one of two bullets: you either change the language semantics to resemble something like Rust, or you add instrumentation that turns C into a managed language. Either of these forks is great, but neither is something you can do transparently: the former means breaking existing C code, and the latter means excluding a large percentage fraction of the world’s C code (where the absence of a managed runtime is a hard requirement).

Fil-C bites the second bullet, under the theory that there’s a lot of userspace code that isn’t extremely performance sensitive. And that’s probably true, but I also think it misses the larger trend: that a lot of userspace code is abandonware, and that there’s sufficiently more interest in rewriting it than maintaining it. For that reason alone, I think we’re going to see more userspaces in safe compiled languages, not unsafe ones that have been instrumented into safety.

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

#167

Post by kibwen »

adastra22 wrote: post #144
kibwen wrote: post #138

Earlier quoted context omitted.

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.

The parent's claim wasn't about systems languages.

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

#168

Post by kibwen »

bangaladore wrote: post #141
kibwen wrote: post #137

Earlier quoted context omitted.

> 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.

You continue vaguely asserting "differences" and then retreating when challenged. So please be specific: what differences?

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

#169

Post by mikepurvis »

mrheosuper wrote: post #135
mikepurvis wrote: post #5

Earlier quoted context omitted.

What are the specific aesthetic complaints here? In my limited rust experience, I’ve found that it does a pretty good job of using the ugliness of something like an explicit lifetime to signal to the developer and reader that the code is doing something complicated and non-obvious. Like “here’s a part where the types logic required more help than what the compiler could figure out on its own; here be dragons.” In tha…

I have no specific compaints, but here one example i saw online, and i'm talking from a C dev perspective. let x: Option , std::num::ParseIntError>> = Some(Ok(vec![1, 2, 3])); let flattened = x .map(|r| r.unwrap_or_default()) .unwrap_or_else(|| Vec:: ::new()); I have no idea what the code is doing here, but while reading python or JS code, i can make an educated guess what it's doing. I have no experience with Rust s…

It's a bit unusual for a type to be wrapped in both an option and a result, since they have a lot of overlap. They're both union types, but semantically, Result takes the place of throwing an exception (Ok is your return value or here's the error) while Option takes the place of a pointer (Some is an instance of the underlying type, vs None which the null case).

Normally these union types would be handled with a match, or an if let, eg:

    if let Some(x) = fn_returning_an_option() {
        do_thing_with_x(x);
    } else {
        // handle that it was none
    }
The unwrap functions are basically just shortcuts for this, with the most extreme being unwrap() itself, which simply returns the Ok/Some value if present, and otherwise triggers a panic state resulting in the program exiting.

But all of this is rust forcing the developer to either address the null case, or explicitly put in an "unwrap" to acknowledge that they're not addressing it. This is in contrast to C or C++ where you just myPtr->lol wherever you want, and if myPtr is null then it's a segfault.

So that's the worst of it. The rest is the function chain, which is a bit obscured by lack of indentation, and that the functions are being passed lambdas.

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

#170

Post by kbolino »

Splizard wrote: post #133
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…

> neither of those languages has dynamic linking what do you mean by this?

Neither Go nor Rust define an ABI for themselves. They can use dynamically linked C code just fine but cannot link their own language with all (or even a reasonably broad subset) of its own features. This is not as bad in Rust, where you can fall back to the unsafe C ABI while still having safe Rust on either side, whereas Go cannot have two instances of its runtime active in the same process.

Compare this situation with Java/JVM or C#/.NET, both of which define their own ABIs albeit not for native machine code, or especially Swift, which defines its own native-code ABI.

Post reply on HN