Non-Compliant Code Example
Do not use the character sequence /* within a comment:
/* comment with end comment marker unintentionally omitted security_critical_function(); /* some other comment */
In this example, the call to the security critical function is not executed. It is possible that, in reviewing this page, a reviewer may assume that the code is executed.
In cases where this is the result of an accidental omission, it is useful to use an editor that provides syntax highlighting or formats the code to help identify issues like missing end comment deliminators.
Because missing end deliminators is error prone and often viewed as a mistake, it is recommended that this approach not be used to comment out code.
Compliant Solution
Comment out blocks of code using conditional compilation (e.g., #if, #ifdef), or #ifndef).
#if 0 /* use of critical security function no longer necessary */ security_critical_function(); /* some other comment */ #endif
The text inside a block of code commented-out using #if, #ifdef), or #ifndef must still consist of valid preprocessing tokens. This means that the characters " and ' must each be paired just as in real C code, and the pairs must not cross line boundaries. In particular, an apostrophe within a contracted word looks like the beginning of a character constant. Therefore, natural-language comments and pseudocode should always be written between the comment delimiters /* and */ or following //.
Non-Compliant Code Example
These are some additional examples of comment styles that are confusing and should be avoided:
// */ /* comment, not syntax error */ f = g/**//h; /* equivalent to f = g / h; */ //\ i(); /* part of a two-line comment */ /\ / j(); /* part of a two-line comment */ /*//*/ l(); /* equivalent to l(); */ m = n//**/o + p; /* equivalent to m = n + p; */ a = b //*divisor:*/c +d; /* interpreted as a = b/c +d; in c90 compiler and a = b+d; in c99 compiler */
Compliant Solution
Use a consistent style of commenting:
/* Nice simple comment */ int i; /* counter */
Risk Assessment
Confusion over which instructions are executed and which are not can lead to serious programming errors and vulnerabilities, including denial of service, abnormal program termination, and data integrity violation. This problem is mitigated by the use of interactive development environments (IDE) and editors that use fonts, colors, or other mechanisms to differentiate between comments and code. However, the problem can still manifest itself, for example, when reviewing source code printed at a black and white printer.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
|---|---|---|---|---|---|
MSC04-A |
2 (medium) |
1 (unlikely) |
2 (medium) |
P4 |
L3 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
[[ISO/IEC 9899-1999]] Section 6.4.9, "Comments," and Section 6.10.1, "Conditional inclusion"
[[MISRA 04]] Rule 2.2, "Source code shall only use /* ... */ style comments," Rule 2.3, "The character sequence /* shall not be used within a comment," and Rule 2.4, "Sections of code should not be "commented out"
[[Summit 05]] Question 11.19