I do software security professionally these days.
While it is easier (e.g., almost possible) to do memory corruption/buffer overrun/stack smashing in any language, it is certainly far easier to do so in C and C++. Many languages these days link to C libraries, thus increasing the possibility.
However, much of my work these days is done against .net applications, which is a managed, garbage collected language. The number and frequency of errors in the code is not smaller than with C. It is still possible to get remote code execution through the IIS/.net web stack.
Application security is very difficult, and not very many of us write error-free code.
To me the issue with OpenSSL (and there are still some that remain, although the ones that I know about are not as severe) is that the code is very unclear and hard to reason about. In fact, the best static code analyzers had to be tweaked to see the issue.
Having many years experience in both C and C++, I find that working in Lisp is much easier to make assertions about its fine-grained behavior, pretty much agreeing with your experience.
I would like to rephrase the question: which language makes it easier to reason about a large code base? My vote is for the Lisp family. However, keep in mind one of the best-written programs out there, Qmail, is written in C. There is a lot to be said for who the author/authors are as well as the language.
wglb
On Sat, Apr 12, 2014 at 4:52 PM, David McClain <dbm@refined-audiometrics.com
wrote:
Just curious for other opinions... but wouldn't this (Heartbleed) sort of buffer excess read-back failure have been prevented by utilizing a "safe" language like Lisp or SML?
I used to be an "unsafe" language bigot -- having mastered C/C++ for many years, and actually producing C compilers for a living at one time. I felt there should be no barriers to me as master of my machine, and not the other way around.
But today's software systems are so complex that it boggles the mind to keep track of everything needed. I found during my transition years that I could maintain code bases no larger than an absolute max of 500 KLOC, and that I actually started losing track of details around 100 KLOC. Making the transition to a higher level language like SML or Lisp enabled greater productivity within those limits for me.
Dr. David McClain dbm@refined-audiometrics.com
pro mailing list pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro