Some of these are pretty interesting though. For instance, "avoid using repeated question marks". How is this a problem?
Well you can pretty easily turn something as harmless as a comment into something that absorbs the next line of code. Good luck debugging that one.
<a href="https://www.securecoding.cert.org/confluence/display/seccode/PRE07-C.+Avoid+using+repeated+question+marks" rel="nofollow">https://www.securecoding.cert.org/confluence/display/seccode...</a>
You might also be interested in the MISRA C coding standard, which is geared towards reliability and safety rather than security. The MISRA C standard is fairly strict and mostly (but not entirely) machine checkable.<p>There was a Usenix talk on developing code for Mars rovers in which Gerard Holzmann pointed out that for large projects coding standards are much more effective when you have automated compliance checking.
<a href="https://www.usenix.org/conference/hotdep12/workshop-program/presentation/holzmann" rel="nofollow">https://www.usenix.org/conference/hotdep12/workshop-program/...</a><p>I note that there is a tool for checking the CERT rules called Rosecheckers:
<a href="http://www.cert.org/secure-coding/tools/rosecheckers.cfm" rel="nofollow">http://www.cert.org/secure-coding/tools/rosecheckers.cfm</a>?
It looks like it might be incomplete and/or outdated.<p>And the CERT pages include a reference to a deleted summary of other automated checkers such as Coverity and Klockwork:
<a href="https://www.securecoding.cert.org/confluence/display/seccode/VOID+Automated+Detection+Tools" rel="nofollow">https://www.securecoding.cert.org/confluence/display/seccode...</a>
I investigated this Standard once.<p>See <a href="https://www.securecoding.cert.org/confluence/display/seccode/EXP05-C.+Do+not+cast+away+a+const+qualification" rel="nofollow">https://www.securecoding.cert.org/confluence/display/seccode...</a> and exception EXP05-EX3 in particular.<p>Exception promotes non-standard-compliant (undefined) behavior because it "usually works".
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<p><pre><code> just don't.
</code></pre>
somewhere.<p>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.