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

31–40 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#31

Post by commodoreboxer »

PreInternet01 wrote: post #21
jerf wrote: post #9

Earlier quoted context omitted.

I believe it goes something like, "I have constructed a strawman that Rust claims that all code written in it is automatically safe by all conceivable definitions of safe, but look, ha ha, here's something that detects unsafe code in Rust!", and I don't mean "code marked in unsafe blocks". It's a concatenation of several logical fallacies in a row; equivocation, straw manning, binary thinking about safety, several ot…

[flagged]

> This repository demonstrates that, when using 'safe' Rust, there are still double-digits cases where you may still encounter dread-pirate-UB.

No it doesn't. Miri is for unsafe code. There's no UB in safe Rust by design. Any UB caused without unsafe is considered a bug to be fixed.

Re: Translating All C to Rust (TRACTOR)

#32

Post by keybored »

PreInternet01 wrote: post #18
keybored wrote: post #7

Earlier quoted context omitted.

You linked an interpreter for some kind of internal compiler representation that the Rust compiler uses. What on Earth do you mean?

> What on Earth do you mean? That documented use of safe Rust can easily lead to UB, which this infernal 'internal compiler representation' demonstrates. I'm not even sure what is even remotely confusing about that?

Indeed. There have been UB bugs in the standard library caused by unsafe blocks.

Those are bugs. They are faults in the code. They need to be fixed. They are not UB-as-a-feature like in C/C++. “Well watch out for those traps every time you use this.”

This is like getting mad that a programming language boasts that it produces great binaries and yet the compiler has a test suite to catch bugs in the emitted assembly. That’s literally what you are doing.

Re: Translating All C to Rust (TRACTOR)

#33

Post by childintime »

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…

Hard for humans. But it's DARPA, is it hard for AI? Image classification used to be hard also, today cars drive themselves.

I'd say it's good timing.

Re: Translating All C to Rust (TRACTOR)

#35

Post by woodruffw »

01HNNWZ0MV43FF wrote: post #28
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…

Can't most c++ be machine-lowered to C?

Lowering is typically easier than lifting (or brightening). When you lower, you can erase higher-level semantics that aren't relevant; when you lift, you generally want to compose lower-level program behaviors into their idiomatic (and typically safer) equivalent.

Re: Translating All C to Rust (TRACTOR)

#36

Post by commodoreboxer »

steveklabnik wrote: post #26
commodoreboxer wrote: post #22

Earlier quoted context omitted.

> Miri is an Undefined Behavior detection tool for Rust. It can run binaries and test suites of cargo projects and detect unsafe code that fails to uphold its safety requirements. > ... detect unsafe code that fails ... Show me the documented safe Rust code that causes UB without using any unsafe blocks outside of the standard library.

There are some soundness holes in the implementation that can cause this. Just like any project, the compiler can have bugs. They’ll be fixed just like any bug.

Yes, in particular some interactions with LLVM have caused some frustrating UB. But those are considered implementation bugs, rather than user bugs, and all the conditions Miri states at the top are relevant primarily in unsafe code, which contradicts the OP's point, which is that there are tons of documented cases of UB in safe Rust. This is not true. There are a few documented cases, and most have been fixed. It's nowhere close to the world of C or C++'s UB minefield.

Re: Translating All C to Rust (TRACTOR)

#37

Post by pdimitar »

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 be a real problem, many times over.

> mechanical translation is a poor means of doing so

Agreed. If we could automatically and reliably translate C/C++ to Rust it would have been done already.

> Spend the time planning better architecture and designing a better software system, and find a way to replace it piece by piece.

OK, I am just saying that somewhere along that process people might get a bout of confidence and tell themselves "oh, we're doing C much better now, we no longer write memory safety bugs, can't we stop here?" and they absolutely will. Cue another hilarious buffer overflow CVE 6 months later.

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

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

> One gets the same safety as a gradual Rust rewrite

Maybe, but that sounds fairly uncertain or far from a clear takeaway to me.

Re: Translating All C to Rust (TRACTOR)

#38

Post by leftyspook »

PreInternet01 wrote: post #15
calebpeterson wrote: post #6

Earlier quoted context omitted.

Genuine question: Would you mind explaining to a dev that doesn’t know much (anything) about Rust, how does this settle any debate?

Well, the general 'Rewrite All in Rust' consensus is that it solves all general programming problems, ever . Yet, the linked repository shows a huge list of cases in which simple, documented use of Rust can cause Undefined Behavior (a.k.a. 'UB') Pretty much every argument of Rust advocates against C/C++ boils down to either 'but memory safety' or 'but UB'. Yet there are many convincing counter-arguments that boil dow…

> Well, the general 'Rewrite All in Rust' consensus is that it solves all general programming problems, ever.

a) There is no such consensus. The actual consensus is that even if Rust solved all problems, it would not be financially feasible to rewrite pretty much any substantial project.

b) While Rust does solve many problems, it is nowhere close to solving all safety, otherwise there would be no `unsafe` keyword. Alas, fully proving safety in an impure, turing-complete language is mathematically impossible.

c) The only reason you would think that there's some sort of woke Rust lobby, is if you spend way too much time subjecting yourself to opinions of literal sixteen year olds on twitter.

Re: Translating All C to Rust (TRACTOR)

#40

Post by IshKebab »

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 security significantly with little-to-no effort" type product here. That doesn't mean you shouldn't do a full manual rewrite if you have the resources, but it's better than nothing if you haven't.

Post reply on HN