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

311–320 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#311

Post by RavSS »

pjmlp wrote: post #275
Y_Y wrote: post #273

Earlier quoted context omitted.

I respectfully disagree. GP claimed that nothing has changed [regarding string and array security bugs in C] in 50 years. I responded that many relevant factors have changed, such that people tend to write different code now which is less susceptible to those bugs. Of course the same old bugs are possible, and sometimes good coders will still write them. Still I argue that there has been meaningful change since there…

ISO C89 is exactly like ISO C23 in that regard. CVE database proves that those kind of errors keep coming up in 2024, regardless of those changes. Not only do they keep coming up, the monetary cost of fixing those issues has raised up to a level that now even governments are looking into this.

>ISO C89

Not that it matters, but isn't that technically ANSI C(89)? If I remember correctly, the first ISO C standard is instead C90, which is basically identical to C89.

Re: Translating All C to Rust (TRACTOR)

#312

Post by ajxs »

9659 wrote: post #282
pjmlp wrote: post #244

Earlier quoted context omitted.

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.

it was depressing when RH dropped ada support. sure, it was gcc, but it was so nice to have an ada compiler part of the default gcc installation. gnat needs money. well deserved. but adoption needs a free, easy to install compiler. 5 years ago i had the pleasure of resurrecting a dead system. it was about 30k of ada, lets call it ada 87 (!). unknown compiler, 32 bit, 68K processor, 16 MB memory, unknown OS. code was…

Very cool project! Were you able to build a working 68K GNAT cross-compiler yourself, or did you purchase one from one of the major Ada vendors?

Re: Translating All C to Rust (TRACTOR)

#313

Post by pdimitar »

nanolith wrote: post #271
pjmlp wrote: post #265

Earlier quoted context omitted.

The proven fact that the said technology has failed its purpose, as the C and C++ culture keeps resisting its adoption, is the fact that all CPU vendors are now integrating hardware memory tagging as the ultimate weapon against memory corruption exploits. Solaris has already been doing it since 2015, ARM more recently, we have Microsoft putting the big buckets into CHERI (including custom FPGA boards for testing), th…

> The proven fact that the said technology has failed its purpose, How, because other solutions are being explored? That's not due to a failure of one thing, but because both defense in depth and a desire to fix existing systems with no additional engineering are paths that security researchers and vendors explore. Not everyone will converge on a single solution, even when that solution is practical. Just because som…

> desire to fix existing systems with no additional engineering

I, too, enjoy sci-fi.

> Just because something is not being used universally doesn't mean that it has failed.

You are only correct in the dictionary sense of these words. Fact is that a lot of the programmers are vain creatures prone to ego, and they make their chosen technical stack part of their core identity. This prevents them from being flexible, they get rigid as they age and they become part of the problems they so passionately wanted to fix when they were young.

None of that is made easier by the managerial class that absolutely loves and financially stimulates the programmers who don't want to rock the boat.

So I'd say if the said CBMC, and likely other tools in the same area, has more or less failed if it could not convince a critical mass of C/C++ devs to use it and finally start keeping up with Rust (and the other languages @pjmlp mentioned).

> Moreso, it is not widely known about, and there persists rumors that it requires extraordinary effort, often reinforced by well meaning, but rather outdated advice.

The victims of Heartbleed and many other CVEs don't care. The breaches happened anyway.

I am amazed at your desire to downplay the problem and keep claiming that eventually stuff will work out.

I disagree. And I'll repeat a very core part of my argument: C/C++ devs were handed a monopoly in their areas for decades and they still can't arrive at a set of common techniques that reduce or eliminate memory safety bugs.

I am not impressed. And I am not even a particularly good programmer. Just a diligent guy with average programming ability whose only unique trait is that he refuses to accept the status quo and always looks at how can stuff be improved. But this has taken me a long way.

Re: Translating All C to Rust (TRACTOR)

#314

Post by pdimitar »

nanolith wrote: post #298
pjmlp wrote: post #287

Earlier quoted context omitted.

Complementary, as the ultimate defence wall. Many of the issues caused by C, are solved by Modula-2, Object Pascal and Ada, we didn't need to wait for Rust. But those aren't the languages that come for free with UNIX. Or even better, they would be solved by C itself, if WG 14 cared even a little about providing proper support for slices, proper arrays and proper string types, or even as library vocabulary types. But…

There is nothing wrong with defense in depth. But, this is not where things stop. I make extensive use of bounded model checking in my C development. I also use privilege separation, serialization between separate processes, process isolation, and sandboxing. That's not because bounded model checking has somehow failed, but because humans are fallible. I can formally verify the code I write, but unless I'm running ba…

> I make extensive use of bounded model checking in my C development...

I would absolutely love it if you were the majority, alas you are not.

I emulate exhaustive pattern matching in my main language of choice because it does not have it (it's not Rust or OCaml or Haskell) but because I saw how beneficial and useful it is. And sadly, many of the other devs using that language don't do so, and I have made a good buck going after them and fixing their mistakes.

I don't doubt your abilities as a person. I doubt the abilities of the corpus of C/C++ devs at large.

Re: Translating All C to Rust (TRACTOR)

#315

Post by nanolith »

pdimitar wrote: post #314
nanolith wrote: post #298

Earlier quoted context omitted.

There is nothing wrong with defense in depth. But, this is not where things stop. I make extensive use of bounded model checking in my C development. I also use privilege separation, serialization between separate processes, process isolation, and sandboxing. That's not because bounded model checking has somehow failed, but because humans are fallible. I can formally verify the code I write, but unless I'm running ba…

> I make extensive use of bounded model checking in my C development... I would absolutely love it if you were the majority, alas you are not. I emulate exhaustive pattern matching in my main language of choice because it does not have it (it's not Rust or OCaml or Haskell) but because I saw how beneficial and useful it is. And sadly, many of the other devs using that language don't do so, and I have made a good buck…

Well, that's something I hope to change. The tools required to write safer software exist. They just aren't widely distributed yet.

I can say, without ego, that I'm a reasonably good software developer. But, it is the tooling and process that I use that allows me to build safer software and that makes me a reasonably good developer. The same is true of Rust developers.

I can teach these skills to other developers, and in fact, I have plans to do so.

I don't expect things to change overnight, any more than I expect things to be rewritten in Rust overnight. C++ has been around for nearly 40 years, and software is still written in C. But, we can do better, and we must do better.

Re: Translating All C to Rust (TRACTOR)

#316

Post by pdimitar »

nanolith wrote: post #315
pdimitar wrote: post #314

Earlier quoted context omitted.

> I make extensive use of bounded model checking in my C development... I would absolutely love it if you were the majority, alas you are not. I emulate exhaustive pattern matching in my main language of choice because it does not have it (it's not Rust or OCaml or Haskell) but because I saw how beneficial and useful it is. And sadly, many of the other devs using that language don't do so, and I have made a good buck…

Well, that's something I hope to change. The tools required to write safer software exist. They just aren't widely distributed yet. I can say, without ego, that I'm a reasonably good software developer. But, it is the tooling and process that I use that allows me to build safer software and that makes me a reasonably good developer. The same is true of Rust developers. I can teach these skills to other developers, an…

Fully agreed. I hope you don't take my criticisms and our back and forth as hostile -- they are not.

Re: Translating All C to Rust (TRACTOR)

#317

Post by trealira »

munificent wrote: post #77
jandrese wrote: post #67

Earlier quoted context omitted.

I have to think the approach will be something like "AI summarizes the features of the program into some kind of technical language, then the AI synthesizes Rust code that covers the same feature set". It would be most interesting if the approach was not to feed the program the original program but rather the manual for the program. That said it's rare that a manual captures all of the nuances of the program so a vie…

More like: "AI more or less sort of summarizes the features of the program into some approximate kind of technical language, then the AI synthesizes something not too far from Rust code that hopefully covers aspirationally the same feature set".

Ghidra, which is decompilation software, already manages to produce almost-valid C from assembly, and it does so without AI. I know nothing about how it works, but just from that, I'm guessing that producing almost-valid Rust from C code would be a simpler problem to solve.

Re: Translating All C to Rust (TRACTOR)

#318

Post by nanolith »

pdimitar wrote: post #313
nanolith wrote: post #271

Earlier quoted context omitted.

> The proven fact that the said technology has failed its purpose, How, because other solutions are being explored? That's not due to a failure of one thing, but because both defense in depth and a desire to fix existing systems with no additional engineering are paths that security researchers and vendors explore. Not everyone will converge on a single solution, even when that solution is practical. Just because som…

> desire to fix existing systems with no additional engineering I, too, enjoy sci-fi. > Just because something is not being used universally doesn't mean that it has failed. You are only correct in the dictionary sense of these words. Fact is that a lot of the programmers are vain creatures prone to ego, and they make their chosen technical stack part of their core identity. This prevents them from being flexible, th…

> I, too, enjoy sci-fi

I was characterizing these hardware changes as being fantasy, so I'm glad you agree.

> So I'd say if the said CBMC, and likely other tools in the same area, has more or less failed if it could not convince a critical mass of C/C++ devs to use it

So, in the same vein, Rust has failed because it has only been around for a similar amount of time and people still use C/C++?

> The victims of Heartbleed and many other CVEs don't care. The breaches happened anyway.

I fail to see how a CVE that occurred due to poor engineering practices has anything to do with the adoption of good engineering practices and tooling. Yes, Heartbleed is why we need this tooling.

You are simultaneously arguing that if we could just adopt Rust, our problems would be solved, but since another technology has not yet been adopted, it has failed. Rust isn't adopted due to programmer ego, but the use of tooling that does the same thing as Rust and more has not yet been adopted because it has failed. Do you not see the logical inconsistency in your position?

Re: Translating All C to Rust (TRACTOR)

#319

Post by nanolith »

pdimitar wrote: post #316
nanolith wrote: post #315

Earlier quoted context omitted.

Well, that's something I hope to change. The tools required to write safer software exist. They just aren't widely distributed yet. I can say, without ego, that I'm a reasonably good software developer. But, it is the tooling and process that I use that allows me to build safer software and that makes me a reasonably good developer. The same is true of Rust developers. I can teach these skills to other developers, an…

Fully agreed. I hope you don't take my criticisms and our back and forth as hostile -- they are not.

I don't. Passion is good, and I'm glad we can have a passionate discussion while remaining civil.

We both want the same thing: safer software.

Re: Translating All C to Rust (TRACTOR)

#320

Post by 9659 »

ajxs wrote: post #312
9659 wrote: post #282

Earlier quoted context omitted.

it was depressing when RH dropped ada support. sure, it was gcc, but it was so nice to have an ada compiler part of the default gcc installation. gnat needs money. well deserved. but adoption needs a free, easy to install compiler. 5 years ago i had the pleasure of resurrecting a dead system. it was about 30k of ada, lets call it ada 87 (!). unknown compiler, 32 bit, 68K processor, 16 MB memory, unknown OS. code was…

Very cool project! Were you able to build a working 68K GNAT cross-compiler yourself, or did you purchase one from one of the major Ada vendors?

target was x86_64 / linux. just updated the rpm spec file for the gcc build to enable ada. rebuild and install.

so, changed wordsize, processor, operating system... minimal source code impact.

Post reply on HN