C security software is being massively funded and is very successfully the basis for trillions of business, eg. the linux & windows & mac kernel. But, according to #1 voted random psuedonymous internet commenter, this is obviously a terrible idea.
If C requires me to only code in certain styles and only use certain tools to only get some increase in safety... Why not just use a language that builds safety in from the beginning?
That said, we're just going to continue soldiering on because of horrible programmer attitudes like yours. Everyone wants to believe that they are a unique little snowflake who wouldn't make those kinds of mistakes (oh wait, Coverty couldn't catch Heartbleed, oops) and choose the comfortable fiction of a Just World where people get what they deserve. After all, if people just drove better we wouldn't have so many accidents, so why bother with air bags and seat belts? Better hope everyone else drives better too or you'll be changing all your passwords and keys with the rest of us schlubs no matter how fancy your valgrind test suite is.
Not fair. Iirc the reason Coverity couldn't catch Heartbleed was because the OpenSSL people insisted on rolling their own inferior memory allocation. It would have worked if they just used the system malloc(). Coverity only works for normal programmers, it can't fully mitigate the ingenuity of complete fools.
Of course, my recollection could be wrong. In which case "someone is wrong on the Internet" will apply and someone will quickly set the record straight.
What language actually meets the need? GC'd languages haven't proven themselves useful for things like OSs, databases, or libraries that are deployed extremely widely in many environments.
So what safe, non-GC language are you advocating?
GC is orthogonal to memory safety.
(And all of those things have been successfully been done in GC'd languages.)
I agree that GC and memory safety are orthogonal -- see rust. But there aren't a lot of options if you want safe and non-GC, which was my point.
And GC is just not an option sometimes. GC has been around forever but it just hasn't proven itself in a lot of domains. I don't think it's for lack of trying, I think it's because sometimes you want to manage the memory.
That they aren't more established for this kind of work is both a historical accident (bad moves with regards to licencing, etc) and a result of the cavalier, worse-is-better solutions the industry takes to everything, even when it's counter-productive (e.g with regards to security) that didn't let them catch on.
For some known ones, used at one point or another for those purposes, Ada, Pascal, Oberon, Modula, etc.
New contenders still in development include stuff like Rust, as a GC-optional newer contender. One wonders why it took until 2010+ to see another attempt at these kind of languages, as if we didn't have any issues with C/C++.
What about Lisp Machines?
If a Lisp Machine is doing a global full GC (which it wants to avoid as much as possible), then it does not react in any useful way to inputs, the network, ...
Kinda proves my point.
But even OpenBSD has had its share of local root exploits. They've even had 2 remote root exploits, and so few only because most services are disabled by default.
Additionally, it's worth keeping in mind that the reason for the OpenBSD team forking OpenSSL wasn't Heartbleed, but rather the OpenSSL team's rather terribly coded malloc replacement that did things in there. All of the security research and practices the OpenBSD team typically insists upon couldn't do anything because OpenSSL insisted on running in its own leaky memory box.
Possibly one of the most trustworthy pieces of software there is.
I remember before Heartbleed was discovered everyone was raving about how secure OpenSSL is because it has been around for so long yadda yadda ... Heartbleed was discovered and everyone's suddenly acting "haha I knew it all along .. it was shit".
And if your circle thought OpenSSL was tight, you are hanging in the wrong circles for security. Heart less was exceptionally bad, but OpenSSL for a long time had a couple of security fixes a month on Ubuntu and Debian - that's enough to tell you that you need to follow advisories closely and not trust blindly. And yes, I have been saying that for at least 5 years, before heartbleed was introduced.