Live data from Hacker News

Translating All C to Rust (TRACTOR)

darpa.mil

281–290 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#281
post #276

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…

Hardware is the ultimate castle wall when nothing else fixes the problem at the software level.

That's a rather cynical interpretation of these initiatives. CHERI, for instance, has been in development for twenty years. It predates the general availability of open source tools like CBMC or languages like Rust. But, that doesn't make the concept better or obsolete. It makes it complementary.

Hardware security is complementary to software security. Mitigations at the hardware level, the hypervisor level, and the operation system level complement architectural, process, and tooling decisions made at the software level.

Defense in depth is a good thing. There can always be errors in one layer or another, regardless of software solution, operating system, hypervisor, or hardware. I can wax poetic about current CPU vulnerabilities that must be managed in firmware or operating systems.

Re: Translating All C to Rust (TRACTOR)

#282
post #244
post #157

Earlier quoted context omitted.

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.

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 compiling in 2 days, running in 2 weeks. i needed to change from using 32 bit floats to 64 bit floats (seems positional data is a little more accurate in 2020). 1 declaration in 1 package spec and a recompile, and all my positions are good.

i love that language!

Re: Translating All C to Rust (TRACTOR)

#283
post #275
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.

You've made three true statements, but I don't agree if you're implying that they prove that "nothing has changed". Bugs still appear, but they are significantly less common (per project or line not per year) and not as damaging when they occur. This is a non-trivial change for the better in the realm of C application quality.

There are more slaves in the world now than ever before in history, but global society has still made great progress on eliminating it in the last thousand years.

Re: Translating All C to Rust (TRACTOR)

#284
post #185

Earlier quoted context omitted.

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. a…

In all honesty, I don't see that sort of thing posted except maybe the overly naive excited "omg I love rust" post in /r/rust from someone just learning it which no one should be taking as credible.

I do, however, see people trot out the oft-repeated "rust evangelists want to rewrite everything in rust" or "rust people say programming C++ is a crime against humanity", but it seems to me that's the only place I see this argument. In other words, it's a simple strawman.

Re: Translating All C to Rust (TRACTOR)

#286

Earlier quoted context omitted.

> using AVX This would require using unsafe code. > As in: literally heartbroken. Unable to talk about it. I would hope that this person improves as an engineer, because this isn't particularly professional behavior, from the way you describe it. > "But the compiler said it was okay!" Given that you'd have to use unsafe to do this, the compiler can't say it was okay. It sounds like this person may not fully understan…

It'd require using unsafe code somewhere in the stack. Not necessarily by the mentee. It's possible that the AVX code wasn't properly hidden behind a safe abstraction in a library.

That still means the unsafe code is at fault.

Re: Translating All C to Rust (TRACTOR)

#287
post #276

Earlier quoted context omitted.

Hardware is the ultimate castle wall when nothing else fixes the problem at the software level.

That's a rather cynical interpretation of these initiatives. CHERI, for instance, has been in development for twenty years. It predates the general availability of open source tools like CBMC or languages like Rust. But, that doesn't make the concept better or obsolete . It makes it complementary . Hardware security is complementary to software security. Mitigations at the hardware level, the hypervisor level, and th…

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 what to expect, when even Dennis Ritchie wasn't able to get his approach to slices being worked on by WG 14.

So hardware memory tagging, and sandboxed enclaves it is.

Re: Translating All C to Rust (TRACTOR)

#288
post #274

Earlier quoted context omitted.

The amount of people using stuff like CBMC is like trying to boil the ocean. WG14 can solve those problems, they decided it isn't their priority to fix C.

> The amount of people using stuff CBMC is like trying to boil the ocean. That's like saying, "Getting everyone to use Rust or TDD or X is like trying to boil the ocean." It's impossible to solve all things for all people at once. But, that doesn't mean that we can't advocate for tooling that can be used today to build safer software. This goes beyond C, as such tools and techniques are being ported to many languages…

50 years are more than enough time to improve C's security story.

Re: Translating All C to Rust (TRACTOR)

#289
post #185

Earlier quoted context omitted.

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. a…

I don’t buy it.

People can, in the most neutral way possible, point out facts about how safe or unsafe Rust is compared to C and C++. People will STILL complain about how the Rust zealots are bullying their language. This is how it plays out every time.

You can look at this thread. The “exasperation and sarcasm“ is stupid and one-sided. “But” they always say “that’s just a reaction to a previous debate”–because the Rust zealots are always in the rear-view mirror, never in front of them.

How about complaining about something in Rust… that is bad? Like how un-ergonomic Async is? Or how pointy and awkward the syntax can be? Instead they choose to fight the losing battle over how C and Rust are equally unsafe or how actually Rust’s safety doesn’t matter, depending on the phase of the moon. Then they whine about tone and zealotry when they realize arguing against Rust safety from the C and C++ side is a losing battle and they have run out of arguments.

Re: Translating All C to Rust (TRACTOR)

#290

Earlier quoted context omitted.

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…

Calling Steve Klabnik (of all Core Rust background people, literally all of them) an “absolutist” proves how unreasonable you’re being.

Why do you feel it is unreasonable for this person to have human failings? What label would you find suitable?
Post reply on HN