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

141–150 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#141

Post by akira2501 »

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 get you very much.

Meanwhile you have tons of garbage collected languages that don't even let the programmer touch pointers. Why aren't those considered? The reason is performance. And because Rust programmers "care" so much about performance you're not ever going to solve the fundamental problem with that language.

Do you want performance or safety? You can't have both.

Re: Translating All C to Rust (TRACTOR)

#142

Post by pdimitar »

uecker wrote: post #139
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…

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 are quite average and you can't rely on them going above and beyond to reduce memory safety errors.

So I don't buy the good old argument of "just hire better C programmers". We still have a ton of buffer overflow CVEs regardless.

And I never "pretended it's impossible to avoid safety issues in C". I'll appreciate if you don't clump me in some imaginary group of "Rust proponents".

What I'm saying is this: use the right tool for the job. The C devs have been given decades and yet memory safety CVEs are still prevalent.

What conclusion would you arrive at if you were in my place -- i.e. not coding C for a living for like 18 years now but still witnessing it periodically crapping the bed?

I'm curious of your take on this. Again, what other conclusion would you arrive at?

Re: Translating All C to Rust (TRACTOR)

#143

Post by Animats »

mike_hearn wrote: post #42
childintime wrote: post #33

Earlier quoted context omitted.

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.

Well, Claude 3.5 can do translation from one language to another in a fairly competent manner if the languages are close enough. I've used it for that task myself with success (Java -> JavaScript). But, this isn't just about rewriting code from one language to another. It's about reverse engineering complex information out of the code, which may not be immediately visible in it, and then finding a way to make it "saf…

> But, this isn't just about rewriting code from one language to another. It's about reverse engineering complex information out of the code, which may not be immediately visible in it, and then finding a way to make it "safe" according to Rust's type system. Where's the training data for that? It'd be really hard even for skilled humans.

That might not be too bad.

A combination of a formal system and an LLM might work here. Suppose we see a C function

   void somefn(char* buf, int n);
First question: is "buf" a pointer to an array, or a pointer to a single char? That can be answered by looking at what the function does with "buf", and what callers pass to it.

If it's an array, how big is it? We don't have enough info to know that yet. But a reasonable guess, and one than an LLM might make, is that the length of buf is "n".

Following that assumption, it's reasonable to translate this to Rust as

   fn somefn(buf: &[u8])
and, if n is needed within the function, use

   buf.len()
The next step is to validate that guess. The run-time approach is to write all calls to "somefn" with

   assert!(buf.len() == n);
   somefn(buf, n);
Maybe formal methods can prove the assert true, and we can take it out. Or if a SAT solver or a fuzz tester can generate a counterexample, we know that the guess was wrong and this has to be done the hard way, as

   fn somefn(buf: &[u8], int n)
implying more subscript checks inside "somefn".

The idea is to recognize common C idioms and do clean translations to Rust for them. This should handle a high percentage of cases.

Re: Translating All C to Rust (TRACTOR)

#144

Post by timeon »

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…

> To do anything interesting you will require unsafe blocks. This will not get you very much.

This is not true.

Re: Translating All C to Rust (TRACTOR)

#145

Post by throwup238 »

mburns wrote: post #136
the_snooze wrote: post #59

Earlier quoted context omitted.

DARPA is basically a state-sponsored VC that optimizes for completely different things. Instead of looking for 100x financial returns, they want technical advantages for the United States. The "moat" is the hardness of developing and operationalizing those technologies first.

To be pedantic, In-q-tel is the literal state-sponsored VC. DARPA is a step closer to traditional research labs but there is obviously some overlap. https://en.wikipedia.org/wiki/In-Q-Tel

> DARPA is a step closer to traditional research labs but there is obviously some overlap.

It's more like the NSF but focused on commercial grantees with project management thrown on top to orchestrate everything.

The really unique part is how much independence each program manager has and the term limits that prevent empire building.

Re: Translating All C to Rust (TRACTOR)

#146

Post by pfdietz »

woodruffw wrote: post #60
the_snooze wrote: post #59

Earlier quoted context omitted.

DARPA is basically a state-sponsored VC that optimizes for completely different things. Instead of looking for 100x financial returns, they want technical advantages for the United States. The "moat" is the hardness of developing and operationalizing those technologies first.

DARPA's commercialization track record is decidedly mixed, so the VC comparison is unexpectedly apt :-) (But yes: DARPA's mandate is explicitly to discover and develop the next generation of emerging technologies for military use.)

Decades ago, as my father explained to me, ARPA (no "D" at that time) was happy if 1% of their projects went all the way through to successful deployment. If they had a higher success rate it would mean they weren't aiming high enough.

Re: Translating All C to Rust (TRACTOR)

#147

Post by PaulHoule »

nvy wrote: post #110
wffurr wrote: post #105

Earlier quoted context omitted.

It languished in government work behind a wall of extremely expensive compilers and contractors. Never heard anyone suggest RiiA - Rewrite it in Ada.

GCC contains `gnat` which is a libre Ada compiler. I think Ada has a lot of technical merit but it's just not fashionable the way Rust is, for lots of uninteresting reasons.

I remember Ada getting pushed in a time when there were many in the computer industry that were pushing Pascal as both a systems and a teaching language. Ada was a lot like Pascal which I think caused an immediate violent reaction in some people. (e.g. the implementers of every other programming language were pissed that BASIC was so hegemonic but they never asked "Why?" or if their alternatives were really any better)

In the early 1980s, microcomputer implementations such as UCSD Pascal were absolutely horrific in terms of performance plus missing the features you'd need to do actual systems programming work. In the middle of the decade you saw Turbo Pascal which could compile programs before you aged to death and also extended Pascal sufficiently to compete with C. But then you had C, and the three-letter agencies were still covering up everything they knew about buffer overflows.

Re: Translating All C to Rust (TRACTOR)

#150

Post by pfdietz »

sans-seraph wrote: post #92

I have been aware of this proposed initiative for some time and I find it interesting that it is now becoming public. It is a very ambitious proposal and I agree that this level of ambition is appropriate for DARPA's mission and I wish them well. As a Rust advocate in this domain I have attempted to temper the expectations of those driving this proposal with due respect to the feasibility of automatic translation fro…

How does it relate to the CRAM effort at Grammatech?

https://cpp-rust-assisted-migration.gitlab.io/blog/

Post reply on HN