Hacker News Reader

Comment by runjake | Hacker News Reader

Context: Along with the never ending pressure to migrate a project to new shiny, there is a lot of momentum against C and other memory-unsafe languages.

The US government recently called on everyone to stop using them and move to memory-safe languages.

Regardless, there are practices and tools that significantly help produce safe C code and I feel like more effort should be spent teaching C programmers those.

Edit: Typos and to make the point that I'm not necessarily defending C, just acknowledging it's place. I haven't written a significant amount of C in over 2 decades, probably, aside from microcontroller C.

View on HN

C was my first language, more than thirty years ago. I've heard (and probably myself made) the same arguments over and over and over. But those arguments are lame and wrong.

C cannot be made safe (at scale). It's like asbestos. In fact, C is a hazardous material in exactly the same way as asbestos. Naturally occurring, but over industrialized and deployed far too widely before its dangers were known. Still has its uses but it will fuck you up if you do not use industrial-grade PPE.

Stop using C if you can. Stop arguing other people should use it. There have always been alternatives and the opportunity cost of ecosystems continuing to invest in C has massive externalized costs for the entire industry and society as a whole.

Stop spreading FUD.

Asbestos causes mesothelioma and gruesome death. C does not. Be serious.

When C code is run in machines capable of failing with gruesome death, its unsafeness may indeed result in gruesome death.

> When C code is run in machines capable of failing with gruesome death, its unsafeness may indeed result in gruesome death.

And yet, it never does. It's been powering those types of machines likely longer than you have been alive, and the one exception I can think of where lives were lost, the experts found that the development process was at fault, not the language.

If it was as bad as you make out, we'd have many many many occurrences of this starting in the 80s. We don't.

https://en.wikipedia.org/wiki/Therac-25#Root_causes

Please don't post flamebait or FUD here. The Therac-25 was not programmed in C.

How was this flamebait? It is an example of how bad programming choices/assumptions/guardrails costs lives, a counterargument to the statement of 'And yet, it never does'. Splitting hairs if the language is C or assembly is missing the spirit of the argument, as both those languages share the linguistic footguns that made this horrible situation happen (but hey, it _was_ the 80s and choices of languages was limited!). Though, even allowing the "well ackuacally" cop-out argument, it is trivial to find examples of code in C causing failures due to out-of-bounds usage of memory; these bugs are found constantly (and reported here, on HN!). Now, you would need to argue, "well _none_ of those programs are used in life-saving tech" or "well _none_ of those failures would, could, or did cause injury", to which I call shenanigans. The link drop was meant to do just that.

The claim was "And yet, it [C] never does ['result in gruesome death']."

How many asterisks do you need in order to be technically correct while also missing the point?

The point is simple. Don't make false claims and don't post flame bait.

We need to agree to disagree on this one; the claim that C is fine and does not cause harm due to its multitude of foot-guns, I think, is an egregious and false claim. So don't make false claims and don't post toxic positivity, I guess?

No. We don't need to agree on anything. You. Are. Wrong. And you knew you were wrong when you posted it.

Therac-25 was, as a matter of inarguable and objective historical fact, not programmed in C. Period.

Your continued insistence on this topic even after correction demonstrates clearly that your dishonesty is quite intentional. Shame on you.

You. Missed. The. Point. Shame on you!

> in exactly the same way

C is not known to the state of California to cause cancer.

Not yet

HN is not for flamebait.

But oddly enough, Zig is not a memory-safe language, and yet still heavily pushed on here. There are a number of measures, comparatively, that can be taken to make C safer too. The story on what can be done with C is still evolving, as Fil-C and other related projects shows.

For that matter, there are a number of compiled memory-safe and safer languages: Dlang, Vlang, Golang, etc... who could be discussed and are equally viable choices. And if we are talking about something that needs to be outright safety-critical, Ada and SPARK should definitely be in the debate.

However, all of that doesn't override the right of projects to decide on what language they believe is best for them or what strategies concerning safety that they wish to pursue.

> Golang, etc... who could be discussed and are equally viable choices.

Golang is not 100% zero cost close to metal abstraction. You could add Java and .NET too, but they are not replacement for C obviously.

Pushed != interested in/talked about. People really like to mash together a bunch of random individuals into a single actor/agenda.

Golang is not playing in the same niche as C/C++/Rust/Zig, but we have had countless memory safe languages that are indeed a good fit for many uses where C was previously used.

Depends on the point of view, for Reversec, it does.

https://reversec.com/usb-armory

> In addition to native support for standard operating environments, such as Linux distributions, the USB armory is directly supported by TamaGo, an Reversec Foundry developed framework that provides execution of unencumbered Go applications on bare metal ARM® System-on-Chip (SoC) processors.

> The US government recently called on everyone to stop using them and move to memory-safe languages.

The US government also _really_ (no sarcasm) cares about safety-critical code that can be formally verified, depending on program requirements. DO-178, LOR1, el. al.

Developing those toolchains costs tens of millions, getting them certified costs tens of millions, and then buying those products to use costs 500k-1.5m a pop.

Those toolchains do not exist for rust. I am only aware of these toolchains existing for C, and old C at that.

Hell, rust doesn't even have a formal spec, which is a bit of a roadblock.

https://blog.pictor.us/rust-is-do-178-certifiable/

> While Rust isn’t “certified” out of the box, it provides attributes that facilitate certification. By design, Rust restricts certain low-level operations and enforces strict memory safety rules, effectively shifting much of the error-checking and verification into compile-time. This means that issues that might otherwise be found by multiple external tools in C/C++ are caught early during the Rust build process.

I think your link agrees with me, actually.

https://ferrocene.dev/

DO-178C isn’t there yet, but I believe I heard that it’s coming. In general, Ferrous Systems works with customer demand, which has been more automotive to start.

I believe is may come, that would be really neat.

Actually having it happen, someone is going to be out 10-30 million bucks. And again for each new compiler version.

Qualifying Ferrocene was way, way, way less expensive than that, and they've already had multiple versions of Rust qualified. The incremental qualifications are even easier and cheaper than the initial one is.

26262 is a lot less expensive than DO-178.

I'd believe it, but from talking about this with the Ferrocene folks, there's just structural issues why it was much easier to qualify rustc than it has been to qualify C compilers. This is how they're able to offer the product at a significantly lower price point, and how they've been able to fairly regularly re-qualify new versions quickly.

It is certainly non-trivial.

> With developments such as the Ferrocene-qualified compiler, Rust can now meet all the analysis requirements under DO-178C, one of the most stringent safety-critical standards worldwide.

“Can meet” vs “has met” is the entire difference.

Clearly C “can meet” and “has met” DO-178. So, I posit that more languages than C “can meet” this standard.

Proving it is the very hard, very expensive part.

Oh, and whatever version of the rust compiler that gets certified will be locked down as the only certified toolchain. No more compiler updates every 6 weeks. Unless you go though the whole process again.

Ferrocene has qualified Rust 1.68.2, 1.76.0, 1.79.0, 1.81.0, 1.83.0, 1.86.0, 1.87.0, 1.89.0, with 1.91.0 in the upcoming release.

It's not every six weeks, but it's far faster than once every three years.

The DOD also made the Waterfall method THE standard software development process.

> The DOD also made the Waterfall method THE standard software development process.

I'm sure they also made a few bad decisions too :-P

You mean, "DOW"

Department of Waterfall?

Department of War.

That is not the official name, and it is highly unlikely that it ever will be in the future.

It's worth pointing out the Department of Defense was named the Department of War for over 150 years, up until 1947.

https://en.wikipedia.org/wiki/United_States_Department_of_Wa...

True, but it required congressional approval to change the name then, and it would now as well.

This congress is not likely to approve it. And the next congress, even less so.

That said, "ever" is probably too strong. There's a window wherein the chaos which is currently being actively created by the US will develop to an extent that compels the US (or is sold to US voters as a necessary step) to adopt a foreign policy where it would be the more appropriate title. And if the adults can't manage that with charismatic leadership in the next election cycle or two, we could be right back here again, with quasi-legitimate geopolitical justification for the sort of big-stick wagging we see today.

I honestly think this is the goal, and I'm not sure the American people are up to the challenge of preventing it.

In the UK, War Office --> Ministry of Defence, in the 60s I think.

No. I don't.

Now imagine if every CVE was actually fixed.

How would the three letter agencies then spy on people and deliver their payloads on various target devices?

The governments around the world really need the security holes to exist despite what they say.

Reply on news.ycombinator.com