Just in case someone needs the reference, the onion uses '"no way to prevent this" says only nation where this regularly happens' as a reoccurring article at every major school shooting[0], to highlight the frequency of such events and the fact that nothing has really changed since the last one.<p>[0] <a href="https://www.theonion.com/no-way-to-prevent-this-says-only-nation-where-this-r-1848971668" rel="nofollow">https://www.theonion.com/no-way-to-prevent-this-says-only-na...</a>
I've been doing programming for ~31 years in total and ~22 years professionally and at this point I have lost all hope that programmers at large will ever gain these mythic qualities called "self-reflection" and "introspection".<p>Truth is, these people are simply afraid for their cozy jobs, that's all there is to it. Derivative states of mind like Stockholm Syndrome and Sunk Cost Fallacy are quite normal to appear in these conditions.<p>On OP: I could not agree more. People always downplay their fuck-ups, that's sadly part of being a Homo Sapiens, but the lack of awareness is still both despairing and hilarious to watch.<p>And finally, C/C++'s niches have decreased but these people will not adapt, of course. Almost anything I've done with those languages 15-20 years can today be done with Rust. Or if you are on a tight time budget -- Golang, and you still won't lose too much speed.<p>But sure, "nothing can be done, these things sometimes happen". Sigh.
More broadly:<p>> "No way to prevent $THIS" say users of only language where $THIS regularly happens<p>A weird psychological quirk I've noticed (of myself, and others) is we'll often exhibit a sort of 'programming language xenophobia', where we apathetically accept (or don't even notice) unpleasantries of our language of choice, yet be quite averse to the unpleasantries of other languages.<p>Maybe it's due to sunk cost; time/effort has already been spent finding work arounds for or adapting to the warts of our native tongue, whereas doing so for unfamiliar languages would require additional effort.
Alternative headline should be "But I have been taught that using C++ makes me the better programmer" because the stereotypes of echo chambers on the internet raised a lot of unreflected programmers to be this way.<p>There is a place for C, where there's no alternative. But that place is where 99% of programmers never work, because they are not doing kernel nor firmware development (which, in the meantime, also has a lot of support by and for memory safe VMs and languages).<p>The issue I have with this narcisstic fatigue (similar to the author's point I assume) is that there is no reflection when they fuck up a codebase.<p>The best code is the code that is safe and easy to read, and doesn't need to use "clever tricks" that beginners cannot understand.<p>If you are using some tricks for type casting to implement your ideas into code, you probably should not write code.<p>Code should be dumb and easily maintainable. If it is not, you made the wrong choice for the programming language.
Some of the HN discussion about whether "new projects in C should be allowed" is moot: Fluent Bit was imported into git in 2015 [0] (a few months <i>before</i> Rust's first public release), and may be considerably older than that for all I know.<p>I suppose incidents like this actually do give a reason to "rewrite it in Rust", when "it" is "widely deployed infrastructure written in C". OTOH, I'm sure there were plenty of non-memory-safety bugs introduced and later fixed over the years, and rewriting in Rust will recapitulate that subset of bugs.<p>[0] <a href="https://github.com/fluent/fluent-bit/commit/49269c5ec3c74411943e362cfef85052665ae97f">https://github.com/fluent/fluent-bit/commit/49269c5ec3c74411...</a>
I thought it was going to be about JS and npm, given some of their fiascos [1][2][3]<p>[1] <a href="https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code" rel="nofollow">https://qz.com/646467/how-one-programmer-broke-the-internet-...</a><p>[2] <a href="https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/" rel="nofollow">https://www.bleepingcomputer.com/news/security/dev-corrupts-...</a><p>[3] <a href="https://www.sonatype.com/blog/everything-matters-why-the-npm-package-sparked-controversy" rel="nofollow">https://www.sonatype.com/blog/everything-matters-why-the-npm...</a>
Oh no ... a bug in a C program. This easy bashing on existing C programs is getting boring and annoying.<p>Write a new userspace program? Use <i>anything</i> else, all language shave flaws so pick one which supports the features you need. Want to quickly write something because you are not allowed to rewrite the entire ecosystem you need into a new language since the project will go massively over budged: Use what you can and what's available and accept the risks, which is the 99th percentile of software.
Free Pascal and Lazarus which is a GUI built on it support strings that don't require manual allocation and are counted and reference counted. A huge amount of grief would go away if that library could be supported in the Linux kernel somehow, and all of the string parameters in system calls ported.
> a vulnerability in HTTP parsing code that allows for heap corruption and arbitrary code execution by making a HTTP GET request with a megabyte of the letter 'A' in its body<p>You mean a buffer overflow? Why write so technical then dumb down something that's pretty obvious.
The headline is misleadingly focusing on a soundbite out of the full quote.<p>"It's a shame, but what can we do? There really isn't anything we can do to prevent memory safety vulnerabilities from happening if the programmer doesn't want to write their code in a robust manner." -- Some (uncredited?) C programmer.<p>Does C have more footguns as a low level language? Of course. That's part of the freedom of bringing only the baggage a project needs. Sadly, like many dangerous or sharp tools, incorrect use will lead to harms.<p>If someone has a choice, a safer more modern language can accommodate less skilled practitioners.