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

181–190 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#181

Post by dgacmu »

kragen wrote: post #128
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

Just to be clear to others, Dan is the darpa PM on this - he convinced darpa internally it was worth funding other people to do the work, so he himself / his research group won't be doing this work. He's on leave from Rice for a few years to be a PM at DARPA's I2O.

And while DARPA doesn't directly care about research publications as an outcome, there's certainly a publishable research component to this, as well as a lot of lower papers-per-$ engineering and validation work. A lot of the contracts they hand out end up going to some kind of contractor prime (BBN, Raytheon, that kind of company) with one or more academic subs. The academic subs publish.

Re: Translating All C to Rust (TRACTOR)

#182

Post by suprjami »

usrusr wrote: post #117
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…

If you have dormant code, as in running everywhere but not getting worked on anywhere, a "translate to shitty rust before ever touching again" has a certain appeal. Not the appeal of an obviously good idea: chances are the "shitty rust" created through translation would be so much worse to work on than C with some level of background noise of bugs (that would also be present in the "shitty rust" thanks to faithful tr…

In my experience (supporting a machine-translated codebase which resulted in shitty Java) your theory doesn't play out.

If you give developers a shitty codebase then those developers will leave to work somewhere else.

After a few years of working on this codebase we had 88% turnover. 1 in 10 developers remembered the original project's design philosophy and intention.

It wasn't a good situation.

Re: Translating All C to Rust (TRACTOR)

#183

Post by Asooka »

atiedebee wrote: post #174
rectang wrote: post #168

Earlier quoted context omitted.

> undefined behavior gives the compiler leeway in deciding what a program does, so the more undefined behavior a C program invokes, the easier it is to translate its code to rust. That's the kind of language lawyer approach that caused a rebellion in the last decade amongst C programmers against irresponsible compiler optimizations. "Who cares if your program actually works as intended? My optimization is legal accor…

> Who cares if your program actually works as intended? My optimization is legal according to the standard, it's your program that's relying written to exploit loopholes". If your program invokes undefined behaviour, it's invalid and non-portable. Out of bounds array accesses are UB, yet a program containing them may just happen to work. It won't be portable even between different compiler versions. The C standard is…

Doing one funny thing on platform A and a different funny thing on platform B when an edge case arises is way better than completely deleting the code on all platforms with no warning.

Re: Translating All C to Rust (TRACTOR)

#184

Post by woodruffw »

0xbadcafebee wrote: post #173
wffurr wrote: post #69

Earlier quoted context omitted.

But even proficient C and C++ programmers continue to produce code with memory safety issues leading to remote code execution exploits. This argument doesn’t hold up to the actual experience of large C and C++ projects.

They aren't trying to prevent them. It's trivial to prevent them if you actually put effort into it; if you don't, it's going to be vulnerable. This is true of all security concerns.

"You aren't trying hard enough" isn't a serious approach to security: if it was, we wouldn't require seatbelts in cars or health inspections in restaurants.

(It's also not clear that they aren't trying hard enough: Google, Apple, etc. have billions of dollars riding on the safety of their products, but still largely fail to produce memory-safe C and C++ codebases.)

Re: Translating All C to Rust (TRACTOR)

#185

Post by fargle »

keybored wrote: post #118
PreInternet01 wrote: post #71

Earlier quoted context omitted.

Towards general mental health. I'm just a C# wage slave, and I'll admit, when being prompted, that my language, its vendor, its runtime environment, and its general approach are, to put it kindly, flawed . However, as evidenced by the arguments and voting in this thread, Rust proponents will take no criticism, whatsoever . I linked to a GitHub repository that documents many, many instances in which generally safe Rus…

Stoking language flame wars based on hysterical exaggeration has never promoted mental health.

to be fair, from his perspective, it's often the rusty crowd who is stoking the flame wars - this sounds like a reaction to them.

how often do we hear something like "C and C++ are horribly flawed and completely unsafe. it's basically a crime against humankind and gross negligence to use them"?

i get weary of that kind of thing too. i wouldn't approach it by reacting in the same way as the GP comment, but i get it. and it's not really that much of a strawman. it's more exasperation and sarcasm.

personally, i'm very interested in rust. but everytime someone at best "overhypes" it or at worse, outright dogs on other languages, it's a negative point toward dealing with the whole rust ecosystem.

Re: Translating All C to Rust (TRACTOR)

#186

Post by kragen »

dgacmu wrote: post #181
kragen wrote: post #128

Earlier quoted context omitted.

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

Just to be clear to others, Dan is the darpa PM on this - he convinced darpa internally it was worth funding other people to do the work, so he himself / his research group won't be doing this work. He's on leave from Rice for a few years to be a PM at DARPA's I2O. And while DARPA doesn't directly care about research publications as an outcome, there's certainly a publishable research component to this, as well as a…

thank you for the correction; I didn't realize he was the darpa pm

what you describe is exactly my experience as a darpa performer (on a program which dan is apparently now the pm for!)

Re: Translating All C to Rust (TRACTOR)

#187

Post by uecker »

pdimitar wrote: post #142
uecker wrote: post #139

Earlier quoted context omitted.

Rewriting is rarely a good idea in general. Rust proponents like to pretend that it is impossible to avoid safety issues in C while it is automatically given in Rust. But this is not so simply in reality.

I don't like generalizations... in in general. :D (Addressing your "rewrites are rarely a good idea in general" here.) My experience tells me that if a tech stack supports certain safety guarantees by default that this leads to measurable reduction of those safety problems when you switch to the stack. People love convenient defaults, that's a fact of life. The apparently inconvenient truth is that most programmers a…

I am complaining about the usual phrases which are part of the Rust marketing, like the "just hire better C programmer did not work" or the "why are there still CVEs" pseudo arguments, etc.

For example, let's look at the "hire better C programmers does not work" argument. Like every good propaganda it starts with a truism: In this case that even highly skilled C/C++ programmers will make mistakes that could lead to exploitable memory safety issues. The problem comes from exaggerating this to the idea that "all hope is lost and nothing can be done". In reality one can obviously do a lot of things to improve safety in C/C++. And even one short look at CVEs should make it clear that there is often huge room for improvements even with relatively simple measures. For example, a lot of memory safety bugs in C/C++ come from open-coded string or buffer manipulation. But it is not exactly rocket science to abstract this away behind a safer interface. But once this is understood, the obvious conclusion is that addressing some of these low-hanging fruits would be far more effective in improving safety than wasting a lot of time and effort in rewriting in Rust.

Re: Translating All C to Rust (TRACTOR)

#188

Post by bigstrat2003 »

akira2501 wrote: post #141
commodoreboxer wrote: post #51

A lot of people are reading this as a call or demand to translate all C and C++ code to Rust, but (despite the catchy project name), I don't read the abstract in that way. There are two related but separate paragraphs. 1. C and C++ just aren't safe enough at large. Even with careful programming and good tooling, so many vulnerabilities are caused by their unsafe by default designs. Therefore, as much code as possible…

> or written in "safe" languages So when those languages have 'unsafe' constructs what are the rules going to be around using those? Without a defining set of rules to use here you're just going to end up right back where you started. > to migrate to safe languages, which Rust is an example of Rust has a safe mode. It is _not_ a safe language. To do anything interesting you will require unsafe blocks. This will not g…

> Rust has a safe mode. It is _not_ a safe language. To do anything interesting you will require unsafe blocks. This will not get you very much.

1. There are plenty of interesting programs which don't require unsafe.

2. Even if your program does require unsafe, Rust still limits where the unsafety is. This lets you focus your scrutiny on the small section of the program which is critical for safety guarantees to hold. That is still a win.

Re: Translating All C to Rust (TRACTOR)

#189

Post by clintfred »

Animats wrote: post #91

It's good to see DARPA pushing on this. It's a hard problem, but by no means impossible. Translating to safe Rust, though, is going to be really tough. There's a C to Rust translator now, but what comes out is horrible Rust, which just rewrites C pointer manipulation as unsafe Rust struct manipulation. The result is less maintainable than the original. So what would it take to actually do this right? The two big prob…

Even if just all the unsafe areas were marked, wouldn't that be valuable? At least it would focus review efforts on the parts with the most risk?
Post reply on HN