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

51–60 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#51

Post by commodoreboxer »

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 should be translated to or written in "safe" languages (especially ones that guarantee memory safety).

2. We are funding and calling for software to translate existing C code into Rust.

It's not a consensus to rewrite the world in Rust. It's a consensus to migrate to safe languages, which Rust is an example of, and a program that targets Rust in such migration.

Re: Translating All C to Rust (TRACTOR)

#52

Post by mike_hearn »

TinkersW wrote: post #46
mike_hearn wrote: post #42

Earlier quoted context omitted.

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…

std::vector [] has had bounds checking since forever if you set the correct compiler flag. Since they aren't using it this is a choice, presumably they prefer the speed gain.

You mean _GLIBCXX_DEBUG? It's got some issues. Linux only, it doesn't always work [1] and it's all or nothing. What's really needed is the ability to selectively opt-out on a per-instantiation level so very hot paths can keep the needed performance whilst all the rest gets opted into safety checks.

Microsoft has this:

https://learn.microsoft.com/en-us/cpp/standard-library/safe-...

but it doesn't seem to actually make std::vector[] safe.

It's frustrating that low hanging fruit like this doesn't get harvested.

[1] "although there are precondition checks for some string operations, e.g. operator[], they will not always be run when using the char and wchar_t specializations (std::string and std::wstring)."

Re: Translating All C to Rust (TRACTOR)

#54

Post by 0xbadcafebee »

Every tool has its own specific quirks. Over many years of using a tool, "expertise" is the intimate knowledge of those quirks and how to use that tool most effectively. Changing tools requires you to gain expertise again. You're going to be less proficient in the new tool for a long time, and make a lot of mistakes.

Considering we already know how to make C/C++ programs memory safe, it's bizarre that people would ditch all of their expertise, and the years and years of perfecting the operation of those programs, and throw all that out the window because they can't be bothered to use a particular set of functions [that enforce memory safety].

If you're going to go to all of the trouble to gain expertise in an entirely new tool, plus porting a legacy program to the new tool, I think you need a better rationale than "it does memory safety now". You should have more to show for your efforts than just that, and take advantage of the situation to add more value.

Re: Translating All C to Rust (TRACTOR)

#55

Post by galangalalgol »

steveklabnik wrote: post #30
PreInternet01 wrote: post #15

Earlier quoted context omitted.

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…

No serious person claims that Rust solves every problem ever. Also, many people cite things like Cargo as a reason to prefer Rust over C and C++, as well as other things. UB is a big part of it, of course, but it isn’t the only thing.

I selected it for performance reasons myself, the UB protection was a nice benefit that was expected, cargo wasn't expected and is extremely nice coming from the cmake,conan,vcpkg and duct tape world I came from.

Re: Translating All C to Rust (TRACTOR)

#56

Post by Calavar »

TinkersW wrote: post #46
mike_hearn wrote: post #42

Earlier quoted context omitted.

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…

std::vector [] has had bounds checking since forever if you set the correct compiler flag. Since they aren't using it this is a choice, presumably they prefer the speed gain.

As far as I am aware, the standard doesn't mandate bounds checking for std::vector::operator[] and probably never will for backwards compatibility reasons. Most standard library implementations have opt-out std::vector[] bounds checking in unoptimized builds, but not in optimized builds.

I tried a toy example with GCC [1], Clang [2], and MSVC [3], and none of them emit bounds checks with basic optimization flags.

[1] https://godbolt.org/z/W5e3n5oWM

[2] https://godbolt.org/z/Pe8nPPvEd

[3] https://godbolt.org/z/YTdv3nabn

Re: Translating All C to Rust (TRACTOR)

#57

Post by timeon »

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.

This is obvious example of strawman. Why are you doing this?

Re: Translating All C to Rust (TRACTOR)

#58

Post by gpm »

niemandhier wrote: post #24

Is this supposed to be automatic ? And if so wouldn’t any Programm that can automatically port c to rust, by necessity contain all the functionality to make the c code itself safe?

I don't think a reasonable reading of the statement implies "fully automated", at which point the answer to the question is no.

Obviously some C code isn't just "not verifiable correct" but "actually wrong in a memory unsafe way". That code isn't going to be automatically translated without human intervention because, how could it be, there is no correct equivalent code. The tooling is going to have to have an escape hatch where it says "I don't know what this code is meant to do, and I know it isn't meant to do what it does do (violate promises to the compiler), help me human".

On a theoretical level it's not possible for that escape hatch to only be used when undefined behaviour does occur (rices theorem). On a practical level it's probably not even desirable to try because obtuse enough code shouldn't just be blindly translated.

So what I imagine the tooling ends up looking like is an interactive tool that does the vast majority of the work for you, but is guided by a human, and ultimately as a result of that human guidance doesn't end up with exactly equivalent code, just code that serves the same purpose.

Re: Translating All C to Rust (TRACTOR)

#59

Post by the_snooze »

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/

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.

Re: Translating All C to Rust (TRACTOR)

#60

Post by woodruffw »

the_snooze wrote: post #59
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/

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

Post reply on HN