I agree with this assessment. There is nothing inherently wrong with C. While alternative languages have certain advantages, there are clear reasons why core foundational libraries like OpenSSL are written in C: portability, age of the code base, knowledge of the contributors, etc.

While I would personally like to see a pragmatic move towards C++ in many of these low level libraries for some of the additional type safety and mechanics the language provides, this is a normative idea only, and I am under no delusion that it would necessarily result in better code. Good software transcends language.

I would, however, like to see enhancements to the style of code being written in this library so that tools like static analyzers and contract verifiers can provide meaningful results. A craftsman is only as good as how well he/she can make use of the available tools. Much of OpenSSL defies analysis, which is why the more bone-headed of these vulnerabilities, such as Heartbleed, are so hard to find.

It's impossible to eliminate all bugs. But, it is possible to build code in such a way that when there is the suspicion of a bug, one has a fairly good idea of how and why it is occurring. It is also possible to structure code -- even C and assembler -- so that it's easier to read and analyze, be this by eye or using tools. Finally, it's possible to structure code so that automated unit testing provides meaningful results regarding boundary conditions and contracts between functions. This latter point isn't meant to find bugs on its own, but rather to codify the more subtle bits of contracts between functions and data structures in a defensive way to ensure that future patches -- like the one that caused Heartbleed -- don't stomp on assumptions made in software.

I was referring to the null deref.