
...
Noncompliant Code Example
Do not use the character sequence /*
within a comment:
Code Block | ||||
---|---|---|---|---|
| ||||
/* commentComment with end comment marker unintentionally ommittedomitted ... security_critical_function(); /* someSome 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 A reviewer examining this page could incorrectly assume that the code is executed.
In cases where this If execution failure is the result of an accidental ommisionomission, it is useful to use an editor that provides syntax highlighting or formats the code to help identify issues like missing end-comment deliminatorsdelimiters.
Because missing end deliminators is delimiters are error prone and often viewed as a mistake, it is recommended that this approach not be used to comment is not recommended for commenting out code.
Compliant
...
Solution (Preprocessor)
Instead of using /*
and */
to comment Comment out blocks of code using condition , use conditional compilation (e.g.for example, #if
, #ifdef
, or #ifdef
#ifndef
).:
Code Block | ||||
---|---|---|---|---|
| ||||
#if 0 /* use * Use of critical security function no * longer necessary. */ security_critical_function(); /* someSome other comment */ #endif |
Non-Compliant Example
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. Consequently, natural-language comments and pseudocode should always be written between the comment delimiters /*
and */
or following //
.
Compliant Solution (Compiler)
This compliant solution takes advantage of the compiler's ability to remove unreachable (dead) code. The code inside the if
block must remain acceptable to the compiler. If other parts of the program, such as macros, types, or function prototypes, later change in a way that would cause syntax errors, the unexecuted code must be brought up to date to correct the problem. Then, if it is needed again in the future, the programmer need only remove the surrounding if
statement and the NOTREACHED
comment.
The NOTREACHED
comment tells some compilers and static analysis tools not to complain about this unreachable code. It also serves as documentation.
Code Block | ||||
---|---|---|---|---|
| ||||
if (0) { /*
* Use of critical security function no
* longer necessary, for now.
*/
/*NOTREACHED*/
security_critical_function();
/* Some other comment */
}
|
This code is an instance of exception MSC07-C-EX2 to MSC07-C. Detect and remove dead code.
Noncompliant Code Example
Following The following are some additional examples of comment styles that are confusing and should be avoided:
Code Block | ||||
---|---|---|---|---|
| ||||
// */ // comment /* Comment, not syntax error */ ... f = g/**//h; //* Equivalent equivalentto toff = g / h; */ ... //\ i(); // part /* Part of a two-line comment */ ... /\ / j(); // part /* Part of a two-line comment ... */ /*//*/ l(); //* equivalentEquivalent to l(); */ ... m = n//**/o + p; // equivalent tom /* Equivalent to m = n + p; |
Compliant Example 1
Use a consistent style of commenting:
Code Block |
---|
// Nice simple comment
int i; // counter
|
*/
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:
Code Block | ||||
---|---|---|---|---|
| ||||
/* Nice simple comment */ int i; /* counterCounter */ |
References
...
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 (IDEs) and editors that use fonts, colors, or other mechanisms to differentiate between comments and code. However, the problem can still manifest, for example, when reviewing source code printed on a black-and-white printer.
Recommendation | Severity | Likelihood | Detectable | Repairable | Priority | Level |
---|---|---|---|---|---|---|
MSC04-C | Medium | Unlikely | Yes | No | P4 | L3 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Astrée |
| mmline-comment | Partially checked | ||||||
GCC |
| Can detect violations of this rule when the | |||||||
| CC2.MSC04 | Fully implemented | |||||||
Helix QAC |
| C3108 | |||||||
LDRA tool suite |
| 119 S, 302 S, 611 S | Partially implemented | ||||||
Parasoft C/C++test |
| CERT_C-MSC04-a | The character sequence /* shall not be used within a C-style comment |
...
The character sequence /* shall not be used within a C++-style comment | |||||||||
PC-lint Plus |
| 1, 427, 602, 689, 853, | Fully supported | ||||||
Polyspace Bug Finder |
| Checks for use of /* and // within a comment (rule partially covered) | |||||||
RuleChecker |
| mmline-comment | Partially checked |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
SEI CERT C++ Coding Standard | VOID MSC04-CPP. Use comments consistently and in a readable fashion |
MISRA C:2012 | Rule 1.2 (advisory) |
Bibliography
...