Comment by o8r3oFTZPE
4 years ago
This thread devolved into a debate over C versus Rust or other memory-safe languages.
1. Blaming the language instead of the programmer will not lead to improved program quality.
2. C will always be available as a user's language. Users will still be write programs in C for their own personal use that are smaller and faster than ones written in memory-safe. languages
3. Those in the future who are practiced in C will have a siginificant advantange in being able to leverage an enormous body of legacy code, of which a ton is written in C. Programmers in the future who are schooled only in memory-safety languages may not be able to approach C as a learning resource, and may in fact be taught to fear it.
There is a tremendous amount of C code that DOES NOT contain buffer overflows or use-after-free errors. It is amazing how easily that work is ignored in these debates. Find me a buffer overflow or use-after-free in one of djb's programs.
> 1. Blaming the language instead of the programmer will not lead to improved program quality.
I disagree. Blaming the language is critically important. Tony Hoare (holds a turing aware, is a genius) puts it well.
> a programming language designer should be responsible for the mistakes that are made by the programmers using the language. [...]
> It's very easy to persuade the customers of your language that everything that goes wrong is their fault and not yours. I rejected that...
[0]
> Users will still be write programs in C for their own personal use that are smaller and faster than ones written in memory-safe. languages
Users will always write C. No they won't always be smaller and faster.
> 3. Those in the future who are practiced in C will have a siginificant advantange in being able to leverage an enormous body of legacy code
Much to society's loss, I'm sure.
> and may in fact be taught to fear it
Cool. Same way we teach people to not roll their own crypto. This is a good thing. Please be more afraid.
> There is a tremendous amount of C code that DOES NOT contain buffer overflows or use-after-free errors.
No one cares. Not only is that not provably the case, nor is it likely the case, but it's also irrelevant when I'm typing on a computer with a C kernel, numerous C libraries, in a C++ browser, or texting someone via a C++ app that has to parse arbitrary text, emojis, videos, etc.
> Find me a buffer overflow or use-after-free in one of djb's programs.
No, that's a stupid waste of my time. Thankfully, others seem more willing to do so[1] - I hate to even entertain such an arbitrary, fallacious benchmark, but it's funny so I'll do it just this once.
[0] http://blog.mattcallanan.net/2010/09/tony-hoare-billion-doll...
[1] http://www.guninski.com/where_do_you_want_billg_to_go_today_...
Guess who is "rolling your crypto" for you. The same guy who is the subject of your "fallacious benchmark". He writes in C. The problem with software is not the languages (seems a new one is created every month), it is a lack of competence in using them. (Over)Confidence is very commmon, competence not so much. I am thankful that Dennis Ritchie created C; I appreciated his humility and I do not blame him for others' mistakes.
It's not a lack of competence because evidence shows that even the most competent C programmers can't write C without security issues - literally every nontrivial security-relevant product that has been written by great C programmers has had them, their competence apparently was not sufficient. I'd argue that nobody, including Dennis Ritchie, is "competent enough" to write secure C - even the best people slip sometimes in ways that (in C!) cause exploitable holes.
"The same guy who is the subject of your fallacious benchmark. He writes in C" and that crypto code, which we used was more secure than rolling our own, but it still is riddled with security bugs because he writes in C (e.g. Heartbleed) - and despite the fact that those particular bugs have been fixed, that code still isn't trustworthy enough just because it's written in C, likely has more issues undetected and needs to be rewritten and replaced eventually with some not-C solution that can remove a whole class of bugs accidentally causing arbitrary code execution. Sure, you'll still have logic bugs - but a logic bug in iMessage image parsing has much lower consequences than a memory safety issue in that same image parsing.
7 replies →