I'm well aware this is full-on "middlebrow dismissal", but still, I feel that in 2015 this standard isn't complete without a chapter saying
just don't.
somewhere.
I understand why a standard like this is necessary, but really it's like a CERT Safe Highway Cycling Standard or a CERT Healthy Smoking Standard. If security is an important enough goal to want to apply this entire standard in detail, maybe there are better options than C.
I wish you were right, but C is still the only way to hit all platforms with a good product. It also still rules performance, which does matter in some cases.
Hopefully this won't still be true in 10 years. Hopefully. But I was hopeful about that 10 yers ago.
Ada is about as portable as C, given that both are implemented as gcc frontends.
For performance, the type-safe SPARK Skein implementation (http://www.adacore.com/press/spark-skein/) matches the C implementation, after the optimizer phases in the compiler were matched up.
While doing the translation from C, they even uncovered a bug in the C implementation.
Anecdata, sure, but that's mostly a popularity issue.
Some people like smoking meth. That's a rather incomplete argument for why it is a good idea.
C/C++ is likely fine for e.g. games programming where speed is of maximum importance and security/verifiability is not.
However in 2015 I would not write nor recommend others write new system services (e.g. DNS, DHCP, web servers, etc) in C or even C++. They're insecure by design and as history has shown us, they cannot be made secure.
That all being said, as there is a massive code base of pre-existing code it is often impractical to not continue these projects in C/C++. It would require tens of years of work to do so. However if an OpenSSL replacement was written in a more secure language with verification being a priority from the ground up, I'd be all over that like a cat on tuna.
Indeed. C (and, to a limited degree C++) are natural choice(s) for embedded and low-level development.
In embedded, there may be other language choices for coding "close to the metal", but they are rarely used, time-costly to work with, and often not well-supported for all platforms. Most micro-controller vendors supply their board-support packages (BSPs) in C, and choosing some other family of (higher level than assembly) language can result in some rather high development costs with few if any benefits in terms of code space or system efficiency.
Not to mention many higher-level languages (and, at least, their compilers or interpreters) are implemented in C (or C++) - Ruby, Python, Lua, etc. Even if one works on desktop applications or web development, C has importance, very likely, at some level in the technology stack.
Those that dismiss C either misunderstand the importance and ubiquity of it as a language and/or inadvertently expose their prejudice towards development at higher levels of abstraction. In any case, C is very likely here to stay, good to know well, and good to know how to code more securely.
Precious few languages have their runtime written in that language, quite a few of them are written in C and so are most mainstream OS's. C is here to stay for a while. Figure another 25 years or so.
I understand why a standard like this is necessary, but really it's like a CERT Safe Highway Cycling Standard or a CERT Healthy Smoking Standard. If security is an important enough goal to want to apply this entire standard in detail, maybe there are better options than C.