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.
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".
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.
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.
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.
But sure, "nothing can be done, these things sometimes happen". Sigh.
You obviously need to perform the correct rites and pay your homage to the blessed machine spirit or the Omnissiah will not permit your code to compile.
> "No way to prevent $THIS" say users of only language where $THIS regularly happens
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.
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.
I would rather have unpleasantries that make the language safer vs unpleasantries that make it more vulnerable. Especially when the unpleasantries in question don’t even make the language easier to use.
There’s probably a large selection bias at work as well – people who care about those specific unpleasantries will avoid that language in the first place.
This is definitely a thing I recognise in myself, a year and a half of writing Scala daily has made me much more prejudiced against Java than I was before.
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.
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).
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.
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.
If you are using some tricks for type casting to implement your ideas into code, you probably should not write code.
Code should be dumb and easily maintainable. If it is not, you made the wrong choice for the programming language.
Kernels have been developed in safer languages already before C became widespread outside Bell Labs, it is a myth that C is even required for that, other than historical baggage.
>But that place is where 99% of programmers never work, because they are not doing kernel development
Certain embedded targets are also legitimate use cases for C. For example, I am currently working on a project using an 8051 microcontroller. Aside from using assembly – which obviously isn't safe either – there is no practical alternative to using C. Rust may be making inroads for 32-bit targets, but will likely never be able to target an 8051.
We now have enough resources to do this. When C was created, we had to do those tricks to have good performance. Currently C is best used for constrained devices, where sometimes you need those tricks.
> If it is not, you, yes ... you, made the wrong choice for the programming language.
Or your project manager or CTO, or some other stakeholder.
> 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.
Forgive my bluntness, but do you even know any C programmers? The ones I know are not at all a homogenous group (there isn't even anything resembling a "C community" - and IMHO that's a good thing btw).
> The best code is the code that is safe and easy to read.
These two things are not really related.
- Rust code is safe, but typically not easy to read
- C code is unsafe, but typically easy to read
...as a counter example though, C++ code is unsafe, and typically not easy to read.
Of course "readability" is entirely subjective too. Seasoned programmers are typically blind to the problems of their language of choice (and that includes C's sloppiness, and Rust's readability). Language beginners typically stumble over problems that experienced users of that language wouldn't even think of.
> Code should be dumb and easily maintainable.
Well, obviously, but see above, one programmers 'dumb and maintainable' is another programmers 'unmaintainable complicated mess'. IME it's harder to write code that's 'dumb and maintenable' in languages that nudge the programmers towards sugarcoating the program logic in high level abstractions than in "simple" languages like C, Go or Zig, because you don't just need to know the language, but also understand the high level abstractions the original author came up with (and which might have been a good fit at the start of the project, but not 3 years later when requirements have changed and the original programmers have long left for greener pastures).
IME it's not 'narcissism' that makes programmers pick C, but the incredible flexibility of the language, combined with being quite predictable what code will be generated (yes, optimizer passes do complex things, but after a while you'll develop an intuition for what the compiler will do, verifiable via godbolt).
Also for instance, look at the hoops other languages are willing to jump through just to get close - but never fully match - what's possible with simple text replacement in the C preprocessor (an incredible hot take, I know).
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 before Rust's first public release), and may be considerably older than that for all I know.
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.
Oh no ... a bug in a C program. This easy bashing on existing C programs is getting boring and annoying.
Write a new userspace program? Use anything 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
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.
"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.
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.
If someone has a choice, a safer more modern language can accommodate less skilled practitioners.
It's a deliberate echo of the famous Onion headline about America's absolutely disgraceful pretence that it couldn't do anything about all the shootings.
> If someone has a choice, a safer more modern language can accommodate less skilled practitioners.
This is the usual mistake. It's not a "skill issue". Footguns are a design mistake, they're much more dangerous than necessary hence the name. As a result the practitioners accomodated by a better language are all those capable of mistake ie all humans.
>If someone has a choice, a safer more modern language can accommodate less skilled practitioners
The implication here is thoroughly debunked. We’ve seen over and over again that memory safety bugs will happen in every C codebase(ignoring toy or small codebases). Even for the mythical and infallible “skilled practitioner” spending time re-solving the solved issues inherent to C just isn’t a good use of developer time.
> a safer more modern language can accommodate less skilled practitioners.
That’s really what it’s all about. SV is absolutely obsessed with hiring bad programmers, treating them like crap, so they don’t stick around, and somehow, magically, forcing them to write good code.
We have this belief that if we just use the “right” tool (in this case, a particular programming language), all of our products will be good. Couple that, with the belief that we should be able to build our stuff on someone else’s code, for free, and you have a recipe for disaster.
People like Linus Torvalds are living proof that it is quite possible to write amazing stuff, in old languages (he is a C guy), but people like that, are rare as hen’s teeth, and may be difficult for today’s tech managers to handle.
There really is no substitute for running a good shop, hiring good people, training them well, treating them well, paying them well, and keeping them around for significant lengths of time.
Also, we need to be able to hold ourselves accountable for the Quality of our own work -regardless of the tools we use. Torvalds is notorious for being a tough taskmaster, because he’s serious about the Quality of his work, and casts that onto others.
“Treating people well” does not mean using kid gloves. It can mean expecting people to act like grown-ups, produce grown-up work, and not accepting less. I worked in an environment like that for decades. It was often quite stressful, but was also personally rewarding.
It isn’t the tools that are broken; it’s the management culture, and no one wants to fix that.
I have a longer nuanced post to write out at some point about my feelings here, but here's the cliff's notes:
We should not be developing new projects in C, and we should make it politically hard to make new projects written in C in distribution repositories. C is going to stay around for a long time and that's okay, but there are so many inherent problems of its design and implementation that make it unsuited for unsupervised use. I wish that we didn't have to make such hard-line stances about this, but people have continuously proven that this tool is unsuitable for modern development and it's only going to get worse as time goes on.
What projects need manual memory management? Those where the hardware costs are comparable to development/maintenance costs. That is much rarer than people think.
RAM is cheap, and few applications really need bespoke allocation. And it's not just a question of skill; even the most disciplined make mistakes. It's one of how much brainpower you want to allocate to... memory allocation.
The lack of memory safety is a property of C implementations, not the language itself. You can have an implementation that reliably crashes on memory errors if you want, though it does get easier if you leave out a few features like casting pointers to ints and back.
This "accommodate less skilled practitioners" you wrote is something that never fails to puzzle me from C/C++ practicing colleagues: the idea that in the problem space there is a high-risk high-reward zone of top performance where only the heroes dare tread.
I am sorry but my observarion is that Nim and LLVM and dare I say even GC-less Java all achieve the same performance as C without the footgun baggage. Sometimes it is good to find a way to move on.
I'm trying to decide if this is a good satirical response to a satirical article? If so, well done!
Because at this point, where can we find programmers who aren't 'less skilled practitioners'? Because it's clear Microsoft, Google, Apple, and major open source projects, have failed to find them based on memory corruption issues in the Linux, Windows and Mac kernels, chrome, and firefox.
[+] [-] fnordian_slip|1 year ago|reply
[0] https://www.theonion.com/no-way-to-prevent-this-says-only-na...
[+] [-] kevincox|1 year ago|reply
https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
[+] [-] voidUpdate|1 year ago|reply
[+] [-] Supermancho|1 year ago|reply
[+] [-] pdimitar|1 year ago|reply
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.
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.
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.
But sure, "nothing can be done, these things sometimes happen". Sigh.
[+] [-] isoprophlex|1 year ago|reply
[+] [-] devjab|1 year ago|reply
[+] [-] Beretta_Vexee|1 year ago|reply
[+] [-] bigiain|1 year ago|reply
[+] [-] nomilk|1 year ago|reply
> "No way to prevent $THIS" say users of only language where $THIS regularly happens
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.
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.
[+] [-] jstimpfle|1 year ago|reply
[+] [-] bsza|1 year ago|reply
[+] [-] JimDabell|1 year ago|reply
[+] [-] BoxOfRain|1 year ago|reply
[+] [-] cookiengineer|1 year ago|reply
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).
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.
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.
If you are using some tricks for type casting to implement your ideas into code, you probably should not write code.
Code should be dumb and easily maintainable. If it is not, you made the wrong choice for the programming language.
[+] [-] pjmlp|1 year ago|reply
[+] [-] phoe-krk|1 year ago|reply
Alternatives to C have started appearing for a long while, and they are quite mature now.
> because they are not doing kernel development
FluentBit, where this error occurred, is a userspace application.
> there is no reflection when they fuck up a codebase
C does not support runtime reflection, that is correct. It's one of the reasons why it's a programming and debugging nightmare.
> If you are using some tricks for type casting to implement your ideas into code
There seem to be no casting issues involved in https://www.tenable.com/security/research/tra-2024-17.
> 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.
It's just a pile of truisms.
Is your whole post even related to this article?
[+] [-] foldr|1 year ago|reply
Certain embedded targets are also legitimate use cases for C. For example, I am currently working on a project using an 8051 microcontroller. Aside from using assembly – which obviously isn't safe either – there is no practical alternative to using C. Rust may be making inroads for 32-bit targets, but will likely never be able to target an 8051.
[+] [-] yetihehe|1 year ago|reply
We now have enough resources to do this. When C was created, we had to do those tricks to have good performance. Currently C is best used for constrained devices, where sometimes you need those tricks.
> If it is not, you, yes ... you, made the wrong choice for the programming language.
Or your project manager or CTO, or some other stakeholder.
[+] [-] consp|1 year ago|reply
Well ... that rules out everyone's pet favourite here to replace c.
[+] [-] flohofwoe|1 year ago|reply
Forgive my bluntness, but do you even know any C programmers? The ones I know are not at all a homogenous group (there isn't even anything resembling a "C community" - and IMHO that's a good thing btw).
> The best code is the code that is safe and easy to read.
These two things are not really related.
- Rust code is safe, but typically not easy to read
- C code is unsafe, but typically easy to read
...as a counter example though, C++ code is unsafe, and typically not easy to read.
Of course "readability" is entirely subjective too. Seasoned programmers are typically blind to the problems of their language of choice (and that includes C's sloppiness, and Rust's readability). Language beginners typically stumble over problems that experienced users of that language wouldn't even think of.
> Code should be dumb and easily maintainable.
Well, obviously, but see above, one programmers 'dumb and maintainable' is another programmers 'unmaintainable complicated mess'. IME it's harder to write code that's 'dumb and maintenable' in languages that nudge the programmers towards sugarcoating the program logic in high level abstractions than in "simple" languages like C, Go or Zig, because you don't just need to know the language, but also understand the high level abstractions the original author came up with (and which might have been a good fit at the start of the project, but not 3 years later when requirements have changed and the original programmers have long left for greener pastures).
IME it's not 'narcissism' that makes programmers pick C, but the incredible flexibility of the language, combined with being quite predictable what code will be generated (yes, optimizer passes do complex things, but after a while you'll develop an intuition for what the compiler will do, verifiable via godbolt).
Also for instance, look at the hoops other languages are willing to jump through just to get close - but never fully match - what's possible with simple text replacement in the C preprocessor (an incredible hot take, I know).
[+] [-] akoboldfrying|1 year ago|reply
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.
[0] https://github.com/fluent/fluent-bit/commit/49269c5ec3c74411...
[+] [-] diego_sandoval|1 year ago|reply
[1] https://qz.com/646467/how-one-programmer-broke-the-internet-...
[2] https://www.bleepingcomputer.com/news/security/dev-corrupts-...
[3] https://www.sonatype.com/blog/everything-matters-why-the-npm...
[+] [-] minikomi|1 year ago|reply
[+] [-] draw_down|1 year ago|reply
[deleted]
[+] [-] consp|1 year ago|reply
Write a new userspace program? Use anything 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.
[+] [-] mikewarot|1 year ago|reply
[+] [-] nubinetwork|1 year ago|reply
You mean a buffer overflow? Why write so technical then dumb down something that's pretty obvious.
[+] [-] davedx|1 year ago|reply
[+] [-] subjectsigma|1 year ago|reply
[+] [-] web007|1 year ago|reply
B) It's a spin on The Onion headline about school shootings.
[+] [-] 1vuio0pswjnm7|1 year ago|reply
[+] [-] Simon_O_Rourke|1 year ago|reply
[+] [-] Hock88sdx|1 year ago|reply
[deleted]
[+] [-] KaiserPro|1 year ago|reply
[+] [-] blueflow|1 year ago|reply
[+] [-] mjevans|1 year ago|reply
"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.
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.
If someone has a choice, a safer more modern language can accommodate less skilled practitioners.
[+] [-] tialaramex|1 year ago|reply
https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
> If someone has a choice, a safer more modern language can accommodate less skilled practitioners.
This is the usual mistake. It's not a "skill issue". Footguns are a design mistake, they're much more dangerous than necessary hence the name. As a result the practitioners accomodated by a better language are all those capable of mistake ie all humans.
[+] [-] l33t7332273|1 year ago|reply
The implication here is thoroughly debunked. We’ve seen over and over again that memory safety bugs will happen in every C codebase(ignoring toy or small codebases). Even for the mythical and infallible “skilled practitioner” spending time re-solving the solved issues inherent to C just isn’t a good use of developer time.
[+] [-] voidUpdate|1 year ago|reply
[+] [-] ChrisMarshallNY|1 year ago|reply
That’s really what it’s all about. SV is absolutely obsessed with hiring bad programmers, treating them like crap, so they don’t stick around, and somehow, magically, forcing them to write good code.
We have this belief that if we just use the “right” tool (in this case, a particular programming language), all of our products will be good. Couple that, with the belief that we should be able to build our stuff on someone else’s code, for free, and you have a recipe for disaster.
People like Linus Torvalds are living proof that it is quite possible to write amazing stuff, in old languages (he is a C guy), but people like that, are rare as hen’s teeth, and may be difficult for today’s tech managers to handle.
There really is no substitute for running a good shop, hiring good people, training them well, treating them well, paying them well, and keeping them around for significant lengths of time.
Also, we need to be able to hold ourselves accountable for the Quality of our own work -regardless of the tools we use. Torvalds is notorious for being a tough taskmaster, because he’s serious about the Quality of his work, and casts that onto others.
“Treating people well” does not mean using kid gloves. It can mean expecting people to act like grown-ups, produce grown-up work, and not accepting less. I worked in an environment like that for decades. It was often quite stressful, but was also personally rewarding.
It isn’t the tools that are broken; it’s the management culture, and no one wants to fix that.
[+] [-] xena|1 year ago|reply
We should not be developing new projects in C, and we should make it politically hard to make new projects written in C in distribution repositories. C is going to stay around for a long time and that's okay, but there are so many inherent problems of its design and implementation that make it unsuited for unsupervised use. I wish that we didn't have to make such hard-line stances about this, but people have continuously proven that this tool is unsuitable for modern development and it's only going to get worse as time goes on.
[+] [-] benjaminl|1 year ago|reply
[+] [-] croes|1 year ago|reply
Nobody writes flawless code.
[+] [-] superb_dev|1 year ago|reply
[+] [-] danuker|1 year ago|reply
What projects need manual memory management? Those where the hardware costs are comparable to development/maintenance costs. That is much rarer than people think.
RAM is cheap, and few applications really need bespoke allocation. And it's not just a question of skill; even the most disciplined make mistakes. It's one of how much brainpower you want to allocate to... memory allocation.
[+] [-] astrange|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] polotics|1 year ago|reply
I am sorry but my observarion is that Nim and LLVM and dare I say even GC-less Java all achieve the same performance as C without the footgun baggage. Sometimes it is good to find a way to move on.
[+] [-] CJefferson|1 year ago|reply
Because at this point, where can we find programmers who aren't 'less skilled practitioners'? Because it's clear Microsoft, Google, Apple, and major open source projects, have failed to find them based on memory corruption issues in the Linux, Windows and Mac kernels, chrome, and firefox.