There's a small set of systems code for which C is a requirement, for various reasons. (There are experimental systems trying to get non-C languages into those areas too, and more power to them.)<p>But today, writing large piles of new C code interacting with untrusted users and data is both painful and irresponsible. Pick a higher-level language, <i>any</i> higher-level language.<p>As far as I can tell, the main thing keeping C in its entrenched position these days isn't performance, or preference; it's C's status as the language of the native platform, that every other decently powerful language can talk to via FFI. If you write a new library in language $FOO, it'll mostly get used by other code in $FOO; if you write a new library in C, many different languages can use it.<p>However, adhering to the C ABI does not require writing code in C. And if enough new libraries start providing a C interface backed by a more powerful language, perhaps we can start establishing careful extensions to the C ABI to better fit higher-level languages (such as standard ways to pass buffers).<p>That's not to say there aren't new classes of systemic bugs in other languages, too. And FFI code, by necessity, lets you write C-like bugs. However, there's no excuse for buffer overflows and integer overflows anymore when any decent high-level language has buffer types and bignums.
This is inflammatory and vapid. OpenSSL just needs better code review and should follow the standards they are programming to. It's not the death knell for an entire programming language.
... not until something else with a sane, stable ABI that everyone agrees upon comes along (and before anyone points it out, I realize C has no actual standard defined ABI, but it doesn't matter in practice because following the OS/arch ABI is always the path of least resistance when linking C).<p>For all of its issues, C is still incredibly important for being the only language you can fairly easily integrate with virtually any other language.
That Pretty Much Wraps it Up for hammers
I love hammers. So damn much. I enjoy using heavy hammers.<p>I love having some nails and some wood and the flexibility to do whatever I want. I love that it imposes a discipline that prevents me from using that flexibility in stupid ways.<p>But between hitting your finger and bent nails I have to wonder if my beloved tool should be retired — at least for everything that could be a carpentry issue. (Which is potentially everything, I suppose.)<p>There are two things that make other tools better for these things: 1) in many tools these particular bugs are impossible, and 2) there are often better tools that can prevent those particular flaws from happening in a chunk of wood.<p>The finger hitting bug is a major hassle. What worries me is that the next time something else might happen — maybe someone hits their toe or breaks their hand. (Or worse.)<p>If we’re serious about protecting ourselves from pain and other malevolent entities, maybe we have to move away from hammers.<p>(I suggest this with great reluctance. And a realization that the cost of this would be huge.)<p>In short, this is click bait and stupid. C is a tool, it's up to the people using it to make sure the tool is used right. What we need is something closer to build codes for software. Right now it looks like some people think that building sky scrapers out of marshmallows is a wonderful idea and anyone pointing out that this is a bad idea is called a Luddite.
The issue is more software architecture than programming languages. DJB writes plenty of C, and manages to create secure systems.<p>If you follow the principle of least privilege and separate things into processes, then you can write secure systems in C. Granted, there is friction with this approach on modern Unix, but it's more than worth it, and much more likely to get done than rewriting all of OpenSSL or OpenSSH or nginx or Python in Rust or whatever.<p>See "Some thoughts on security after 10 years of qmail 1.0":<p><a href="http://scholar.google.com/scholar?cluster=9814570315440570792&hl=en&as_sdt=0,5&sciodt=0,5" rel="nofollow">http://scholar.google.com/scholar?cluster=981457031544057079...</a><p>People can and do write insecure code in any language. The most popular ones seem to be the most insecure -- C, PHP, and JavaScript -- and that doesn't seem to be coincidence (liberal languages have advantages as well as diadvantages).<p>Systems have to be designed so that tiny mistakes aren't catastrophic, and rewriting everything in a different programming language is probably <i>the</i> most costly way of achieving that goal. In other words, it's an economic impossibility.<p>See also: <a href="http://www.cl.cam.ac.uk/research/security/capsicum/" rel="nofollow">http://www.cl.cam.ac.uk/research/security/capsicum/</a> . This works with existing code.
Please, it can happen in any language, it depends on how you write it. If you do not sanitize your inputs you get sql-injected, and is this fault of SQL or you? I agree it is harder to write C code safely, but this was a stupid bug, not actually a C incompetence. You could allocate a large buffer in Java, and you could use `System.arraycopy(array, 0, part, 0, size);` instead of OpenSSL: `memcpy(bp, pl, payload);` both lacks only a boundary check and language provided checks will not help you in Java. Java is given as an example language that provides boundary checks. It applies to others as well.
The problem is that no other language has captured the good points of C anywhere near as good as C. There are ways of using C that are much less likely to result in this type of bug - and the more complex processing that other popular languages can add in surprising places can cause bugs too. I've been meaning to learn ATS that basically adds a separate validation layer to C:
<a href="http://www.ats-lang.org/" rel="nofollow">http://www.ats-lang.org/</a>
For people that think that "C is not the problem":<p><a href="http://queue.acm.org/detail.cfm?id=2010365" rel="nofollow">http://queue.acm.org/detail.cfm?id=2010365</a><p>This is C thing, that have a lot of problems. In pascal, no problem.<p>And the worst?<p>IS STILL A PROBLEM. Decades after.<p>And this is only one thing.<p>The other bug:
<a href="http://www.slate.com/articles/technology/bitwise/2014/02/apple_security_bug_a_critical_flaw_was_extraordinarily_simple.html" rel="nofollow">http://www.slate.com/articles/technology/bitwise/2014/02/app...</a><p>Is a C problem. No just the goto. YEARS AFTER, still here. IS the "brace" thing. Is not mandatory.<p>C have a lot of stupidity built-in (ie: Bad by default):<p><a href="http://www.drpaulcarter.com/cs/common-c-errors.php" rel="nofollow">http://www.drpaulcarter.com/cs/common-c-errors.php</a>
<a href="http://www.andromeda.com/people/ddyer/topten.html" rel="nofollow">http://www.andromeda.com/people/ddyer/topten.html</a><p>Some of this are not corner cases, and could be say are unnecessary to fight them decades after. You know, if B turn to C, why not turn to something better? Instead, the inertia (like happend with javascript) is push and push doing things the hard/dumb way because, well, all that people that have worked better from DECADES, they are wrong.
This has nothing to do with the language and everything to do with the programmers and practices - some great write-ups:<p><a href="http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse" rel="nofollow">http://www.tedunangst.com/flak/post/analysis-of-openssl-free...</a><p>Who can resist Theo: <a href="http://article.gmane.org/gmane.os.openbsd.misc/211963" rel="nofollow">http://article.gmane.org/gmane.os.openbsd.misc/211963</a>
> I love that it imposes a discipline that prevents me from using that flexibility in stupid ways.<p>What discipline? Am I missing something?<p>> maybe we have to move away from C.<p>Hopefully, Rust will facilitate this transfer.
Overreaction. With enough eyes all bugs are shallow. Look at Linux and BSD vs BeOS or something.<p>If you want safe operations in C, just write a few simple functions and use those.
Just because of bad programming practices you are diminishing the language. If I'm allowed to make an analogy to what you said, it is the same as cutting a tree because we found a rotten fruit. I agree with the @CSDude arg, every language has its weaknesses and a good developer should recognize and understand that.
Oh come on. People that know of the pitfalls build useful abstractions that keep someone falling in from burning down the house. Look to the Linux kernel for evidence of C being used by responsible people, not morons that can't rise above hacking on raw memory straight out the socket.