Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: REM Cost Reform

...

Code Block
bgColor#FFcccc
langc

/* commentComment with end comment marker unintentionally omitted
security_critical_function();
/* someSome other comment */

In this example, the call to the security-critical function is not executed. It is possible that a 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 omission, it is useful to use an editor that provides syntax highlighting or formats the code to help identify issues like missing end-comment delimitorsdelimiters.

Because missing end delimitors delimiters are error prone and often viewed as a mistake, this approach is not recommended for commenting out code.

...

Instead of using /* and */ to comment out blocks of code, comment out blocks of code using use conditional compilation (for example, #if, #ifdef, or #ifndef).:

Code Block
bgColor#ccccff
langc

#if 0  /*
        * useUse of critical security function no
        * longer necessary.
        */
security_critical_function();
/* someSome 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. Consequently, natural-language comments and pseudocode should always be written between the comment delimiters /* and */ or following //.

...

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 later 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, all that must be done is to 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
bgColor#ccccff
langc

if (0) {  /* use
           * Use of critical security function no
           * longer necessary, for now.
           */
  /*NOTREACHED*/
  security_critical_function();
  /* someSome other comment */
}

This code is an instance of exception MSC07-C-EX2 to recommendation MSC07-C. Detect and remove dead code.

Noncompliant Code Example

These Following are some additional examples of comment styles that are confusing and should be avoided:

Code Block
bgColor#FFcccc
langc

// */          /* commentComment, not syntax error */

f = g/**//h;   /* equivalentEquivalent to f = g / h; */

//\
i();           /* partPart of a two-line comment */

/\
/ j();         /* partPart of a two-line comment */


/*//*/ l();    /* equivalentEquivalent to l(); */

m = n//**/o
+ p;           /* equivalentEquivalent to m = n + p; */

a = b //*divisor:*/c
+d;            /*
                * interpretedInterpreted 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
bgColor#ccccff
langc

/* Nice simple comment */

int i; /* counterCounter */

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 itself, for example, when reviewing source code printed on a black-and-white printer.

Recommendation

Severity

Likelihood

Remediation Cost

Detectable

Repairable

Priority

Level

MSC04-C

medium

Medium

Unlikely

unlikely

Yes

medium

No

P4

L3

Automated Detection

Tool

Version

Checker

Description

section
Astrée

LDRA tool suite

Include Page
LDRA
Astrée_V
LDRA
Astrée_V
Section

119 S
302 S

Section

Partially Implemented

mmline-comment
sline-comment
sline-splicing
smline-comment

Partially checked
section Sectioncan
GCC
Include Page
GCC_V
GCC_V

 


Can detect violations of this rule when the -Wcomment flag is used

ECLAIR

Include Page
ECLAIR_V
ECLAIR_V

CC2.MSC04

Fully implemented

Helix QAC

Include Page
Helix QAC_V
Helix QAC_V

C3108
LDRA tool suite
Include Page
LDRA_V
LDRA_V
119 S, 302 S, 611 S

Partially implemented

Parasoft C/C++test
Include Page
Parasoft_V
Parasoft_V

CERT_C-MSC04-a
CERT_C-MSC04-b
CERT_C-MSC04-c
CERT_C-MSC04-d

The character sequence /* shall not be used within a C-style comment
The character sequence // shall not be used within a C-style comment
The character sequence /* shall not be used within a C++-style comment
Line-splicing shall not be used in // comments

PC-lint Plus

Include Page
PC-lint Plus_V
PC-lint Plus_V

1, 427, 602, 689, 853,
9059, 9060, 9066, 9259

Fully supported

Polyspace Bug Finder

Include Page
Polyspace Bug Finder_V
Polyspace Bug Finder_V

CERT C: Rec. MSC04-C


Checks for use of /* and // within a comment (rule partially covered)

RuleChecker
Include Page
RuleChecker_V
RuleChecker_V

mmline-comment
sline-comment
sline-splicing
smline-comment

Partially checked

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

...

...

ISO/IEC 9899:1999 Section 6.4.9, "Comments," and Section 6.10.1, "Conditional inclusion"

...

MISRA C:2012

Rule 1.2 (advisory)
Rule 3.1 (required)
Directive 4.4 (advisory)

Bibliography


...

Image Modified Image Modified Image Modified