Non-Compliant Code Example
Do not use the character sequence /* within a comment:
...
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 or #ifdef).
| Code Block |
|---|
#if 0 /* use of critical security function no longer necessary */ security_critical_function(); /* some other comment */ #endif |
Non-Compliant Code Example
These are some additional examples of comment styles that are confusing and should be avoided:
| Code Block |
|---|
// */ // 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 tom = n + p; |
Compliant Solution 1
Use a consistent style of commenting:
| Code Block |
|---|
// Nice simple comment int i; // counter |
Compliant Solution 2
Use a consistent style of commenting:
| Code Block |
|---|
/* Nice simple comment */ int i; /* counter */ |
Priority: P6 Level: L2
Confusion over which instructions are executed and which are not can lead to serious programming errors and vulnerabilities. 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.
Component | Value |
|---|---|
Severity | 3 (high) |
Likelihood | 1 (unlikely) |
Remediation cost | 1 (med) |
References
- ISO/IEC 9899-1999 6.4.9 Comments
- MISRA 04 Rule 2.3: The character sequence /* shall not be used within a comment; Rule 2.4: Sections of code should not be "commented out"