Live data from Hacker News

Translating All C to Rust (TRACTOR)

darpa.mil

241–250 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#241

Earlier quoted context omitted.

Opinions about automated driving systems vary. Just from my own experience doing business all around San Francisco I have seen at least a half dozen instances of Waymo vehicles making unsafe maneuvers. Responders have told me and local government officials that Waymo vehicles frequently fail to acknowledge emergency situations or respond to driving instructions. Driving is a social exercise which requires understandi…

they're not perfect, sure, but they're out there, just driving around all autonomously and all, contrary to GGP's assertion that they don't exist.

GGGP talked about L5 self-driving, isn't Waymo L4?

Re: Translating All C to Rust (TRACTOR)

#242

Earlier quoted context omitted.

> In reality one can obviously do a lot of things to improve safety in C/C++. That's not "in reality", that's "in theory". Because in actual reality, people still write the good old buffer overflow bugs to this day. I don't think anyone reasonable is disputing that we indeed can improve C/C++ programming. The argument of myself and many others like myself is: "a lot can be done but for one reason or another it is STI…

> That's not "in reality", that's "in theory". Because in actual reality, people still write the good old buffer overflow bugs to this day. That's because while the technology exists, it is not widely communicated. That's not a fault of C, and that's not something that any language can solve. > Explain why this has not been done yet. See above. The technology to make C and C++ safer is not yet widely used. But, it ex…

Bounded model checking is not a silver bullet. If you want to prove it is, verify a Web browser and blog about it.

Re: Translating All C to Rust (TRACTOR)

#243

Earlier quoted context omitted.

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…

It doesn't make sense to convert a C array to a Vec, the Vec type is a growable array but the C array isn't growable. It makes sense to convert to Rust's array type, which has a fixed size, and we realise there's a problem at API boundaries because C's arrays decay to pointers, so the moment we touch an API boundary all safety is destroyed.

Depends on how the array is created. If it comes from "malloc" or C++ "new", it may need to be created as a "Vec".

Re: Translating All C to Rust (TRACTOR)

#244
post #157

Earlier quoted context omitted.

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.

ada does not require 'pushing'. once the maturity of the users advances to a sufficient point, then ada is the only solution. "ada. used in creating reliable software since 1983" when i first saw ada, i didn't understand the why. now i understand the why, but ada is effectively gone. -- old fortran / C / Assembly programmer

Ada is still around, at a big enough level to keep 7 commercial vendors selling compilers.

Something unheard of, paying for software tools in 2024, who would imagine that.

Re: Translating All C to Rust (TRACTOR)

#245

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?

Yes, that is after all how C++ started.

How good the resulting performance would be like, that is another matter.

Re: Translating All C to Rust (TRACTOR)

#246

Earlier quoted context omitted.

If the IRS could have more timely funding, all their Cobol would be translated to Java by now

COBOL migrations are tar pits of replicating 40+ years of undocumented niche business logic for a given field, edge cases included, that was "commonly understood" by people who are now retired or dead. Don't get your hopes up.

MicroFocus has COBOL compilers for Java and .NET, as do other COBOL vendors still in business.

Usually the biggest issue, is that most of the porting attempts don't start there, rather they go for the rewritte from scratch, and lets not pay the licenses for those cross-compilers.

Re: Translating All C to Rust (TRACTOR)

#247

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…

> Make std::vector[] properly bounds checked

Most compilers do have flags to turn this on, which I use all the time.

The issue is the "performance trumps safety" culture that pushes back against using them.

Re: Translating All C to Rust (TRACTOR)

#248

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…

Modern C still has the same security exploits in arrays and strings as Classical C, nothing changed in 50 years.

Re: Translating All C to Rust (TRACTOR)

#249

Earlier quoted context omitted.

Yes, it is a core design tenet of the language. It's as benign a statement as "C# has garbage collection." That's not "reluctant to offer compromise."

OK, you truly seem not to understand how much damage you're dealing to the general population using absolutist statements like this, do you? Nor do you seem to understand "compromise", like at all , because you seem to equate it with "tit for that", which is unsurprising, but still... disappointing. In any case, I'm truly done here, in all senses of the word, but I still I wish you and your acolytes the absolute best…

Man all you had to do was bring proof, like maybe a code snippet with UB?

Re: Translating All C to Rust (TRACTOR)

#250

Earlier quoted context omitted.

> This is not true. Burying unsafe blocks in unevaluated cargo modules does not make this true. You're just taking the original problem and sweeping it under the rug.

You can do tons of stuff with purely safe Rust. The main things that you can't do are FFI, making self-referential structures, and dereferencing raw pointers. And unsafe isn't a problem. It's a point of potential danger to be heavily audited, tested, and understood. Having the entire language unsafe by default is an obviously worse situation. This is throwing the baby out with the bathwater, like rallying against sea…

> I don't understand why people criticizing Rust tend so heavily to let perfect be the enemy of good.

if you've convinced yourself that you're special and all problems with c are solved by trying harder, clearly everyone else is just lazy. with that line of logic, there's nothing to fix with c. rust is not just redundant, but also aggravating, since its popularity causes the cognitive dissonance to start creeping in.

maybe i can make mistakes? should we improve tooling somewhat? no, it's the children who are wrong.

Post reply on HN