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

Translating All C to Rust (TRACTOR)

darpa.mil

Post reply on HN
Print view View original

121–130 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#121

Post by marcosdumay »

Animats wrote: post #103
jcalvinowens wrote: post #70

This isn't some "pie in the sky" thing, Immunant has a working C to Rust transpiler and it's really interesting: https://github.com/immunant/c2rust

I've tried that thing. The Rust that comes out is terrible. It converts C into a set of Rust function calls which explicitly emulate C semantics by manipulating raw pointers. It doesn't even convert C arrays to a Vec. It's a brute-force transliteration, not a translation. I and someone else ran this on a JPEG 2000 decoder that sometimes crashed with a bad memory reference. The Rust version crashed with the same bad m…

Any automatic translation is bug-compatible with the original. Did you expect it to divine some requirements?

It still leave you with Rust code that you can improve piecewise. The only question is if something like it is better than FFI calling the C code.

Re: Translating All C to Rust (TRACTOR)

#123

Post by jcranmer »

PreInternet01 wrote: post #88
steveklabnik wrote: post #68

Earlier quoted context omitted.

No, people are not claiming Rust cannot have any problems. UB is not possible in safe Rust, by design. The root cause of UB is always in unsafe code. Miri is useless if your code is 100% safe Rust. The only exception to this is bugs in the compiler, of which there are a few. They’ll be fixed.

> UB is not possible in safe Rust, by design You're available as an expert witness to that fact ? Because, eh, well, in at least one of the Rust-related situations that I'm involved in right now, someone might soon very well require the services of a person both as wise and reluctant-to-offer-any-kind-of-compromise as yourself...

The situation you've alluded to in another thread seems to involve an unsafe block (since it's using a type which is only usable in an unsafe block).

Let me be even more explicit than steveklabnik here. If your code, including any libraries you link to, is 100% Rust and free of any unsafe blocks, then (barring compiler bugs) it is impossible to execute undefined behavior. If your code has an unsafe block, then it is possible execute undefined behavior. Note that it is possible for safe code to execute undefined behavior, IF there was an unsafe block that did an operation that requires the programmer to promise something was true that was not true.

For example, there is an unsafe method that will let you convert a pointer to a reference with an arbitrary lifetime. If you wrap that in a safe function, you can return a reference to an object whose lifetime has ended, and cause undefined behavior in attempting to use that lifetime--the attempt can even be outside the safe block. But were that unsafe block that upgraded the lifetime not present, then you couldn't cause the later undefined behavior to happen.

In short, an unsafe block is where the compiler can no longer guarantee that the conditions that prevent the ability to observe undefined behavior are present, and it is up to the programmer to ensure that these conditions are met, and even and especially ensure that they continue to be met after the unsafe block completes. I do worry that too many programmers are blasé about the last bit, and it sounds like your coworker may fall into that category. But Rust has always maintained this principle.

Re: Translating All C to Rust (TRACTOR)

#124

Post by Slyfox33 »

PreInternet01 wrote: post #88
steveklabnik wrote: post #68

Earlier quoted context omitted.

No, people are not claiming Rust cannot have any problems. UB is not possible in safe Rust, by design. The root cause of UB is always in unsafe code. Miri is useless if your code is 100% safe Rust. The only exception to this is bugs in the compiler, of which there are a few. They’ll be fixed.

> UB is not possible in safe Rust, by design You're available as an expert witness to that fact ? Because, eh, well, in at least one of the Rust-related situations that I'm involved in right now, someone might soon very well require the services of a person both as wise and reluctant-to-offer-any-kind-of-compromise as yourself...

What are you talking about? Yes it's impossible to have UB in safe rust unless theres some obscure compiler bug or something. This isn't a controversial statement.

Re: Translating All C to Rust (TRACTOR)

#125

Post by fsckboy »

woodruffw wrote: post #25
mike_hearn wrote: post #10

That sounds ... hard. Especially as idiomatic Rust as written by skilled programmers looks nothing like C, and most interesting code is written in C++ anyway. Isn't it equivalent to statically determining the lifetimes of all allocations in the C program, including those that are implemented using custom allocators or which cross into proprietary libraries? There's been a lot of research into this sort of thing over…

It's very hard; DARPA likes to fund hard things[1] :-). This isn't, however, DARPA's first foray into automatic program translation, or even automatic translation into Rust[2]. [1]: https://www.urbandictionary.com/define.php?term=DARPA%20hard [2]: https://c2rust.com/

in this case it seems to me the hard task that DARPA has chosen is to get me to forget how much they spent on pushing Ada.

Re: Translating All C to Rust (TRACTOR)

#126

Post by nanolith »

IshKebab wrote: post #40
nanolith wrote: post #27

I'm personally not a fan of "rewrite the world in Rust" mentality, but that being said, if one is planning to port a project to a new language or platform, mechanical translation is a poor means of doing so. Spend the time planning better architecture and designing a better software system, and find a way to replace it piece by piece. Don't build a castle in the sky, because it will never reach the ground. If you've…

> I think a far better and more mature process is to update C to modern C and use a model checker such as CBMC to verify memory, resource, and integer math safety. No chance. CBMC is amazing, but have you actually tried formally verifying a "real" program? I agree replacing with a hand-architected Rust version is clearly the better solution but also more expensive. I think they're going for an RLBox style "improve se…

> No chance. CBMC is amazing, but have you actually tried formally verifying a "real" program?

Yes. Every day. It's actually quite easy to do. Write shadow methods covering the resources and function contracts of called functions, then verify the function. Repeat all of the way up and down the stack. It adds about 30% overhead over just TDD development.

Re: Translating All C to Rust (TRACTOR)

#127

Post by nanolith »

pdimitar wrote: post #37
nanolith wrote: post #27

I'm personally not a fan of "rewrite the world in Rust" mentality, but that being said, if one is planning to port a project to a new language or platform, mechanical translation is a poor means of doing so. Spend the time planning better architecture and designing a better software system, and find a way to replace it piece by piece. Don't build a castle in the sky, because it will never reach the ground. If you've…

> I'm personally not a fan of "rewrite the world in Rust" mentality There is no such mentality anywhere. There is a ton of software that's much better off left alone in a dynamic language, or a statically typed language with a garbage collector (like Golang). Good engineers understand the idea of using the right tool for the job. The push is to start reducing those memory safety CVEs because they have been proven to…

> A huge investment. If you are going to do that then you might as well just move to Rust.

People say that, but the people who say this rarely have any practical experience using CBMC. It's very straight-forward to use. I could teach a developer to use it reliably, on practical software, in a month.

Re: Translating All C to Rust (TRACTOR)

#128

Post by kragen »

mike_hearn wrote: post #10

That sounds ... hard. Especially as idiomatic Rust as written by skilled programmers looks nothing like C, and most interesting code is written in C++ anyway. Isn't it equivalent to statically determining the lifetimes of all allocations in the C program, including those that are implemented using custom allocators or which cross into proprietary libraries? There's been a lot of research into this sort of thing over…

presumably dan wouldn't have gotten darpa funding if it were obviously feasible, and success wouldn't give him anything publishable academically

Re: Translating All C to Rust (TRACTOR)

#129

Post by woodruffw »

fsckboy wrote: post #125
woodruffw wrote: post #25

Earlier quoted context omitted.

It's very hard; DARPA likes to fund hard things[1] :-). This isn't, however, DARPA's first foray into automatic program translation, or even automatic translation into Rust[2]. [1]: https://www.urbandictionary.com/define.php?term=DARPA%20hard [2]: https://c2rust.com/

in this case it seems to me the hard task that DARPA has chosen is to get me to forget how much they spent on pushing Ada.

I can't find any clear references to DARPA (or ARPA) being involved in Ada's development. It was a DoD program but, well, the DoD is notoriously large and multi-headed.

(But even if DARPA was involved in Ada: I think it's clear, at this point, that Ada has been a resounding success in a small number of domains without successfully breaking into general-purpose adoption. I don't have a particular value judgment associated with that, but from a strategic perspective it makes a lot of sense for DARPA to focus program analysis research on popular general-purpose languages -- there's just more labor and talent available.)

Re: Translating All C to Rust (TRACTOR)

#130

Post by pdimitar »

nanolith wrote: post #127
pdimitar wrote: post #37

Earlier quoted context omitted.

> I'm personally not a fan of "rewrite the world in Rust" mentality There is no such mentality anywhere. There is a ton of software that's much better off left alone in a dynamic language, or a statically typed language with a garbage collector (like Golang). Good engineers understand the idea of using the right tool for the job. The push is to start reducing those memory safety CVEs because they have been proven to…

> A huge investment. If you are going to do that then you might as well just move to Rust. People say that, but the people who say this rarely have any practical experience using CBMC. It's very straight-forward to use. I could teach a developer to use it reliably, on practical software, in a month.

I am not denying it, nor am I claiming that "just move to Rust" is an universal escape hatch.

What I am saying is that if it were as simple as "just learn CBMC" then maybe Microsoft and Google would have not published their studies demonstrating that 60% - 75% of all CVEs are memory safety errors like buffer under-/over-flows.

Post reply on HN