Skip to end of metadata
Go to start of metadata

Noncompliant 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. A reviewer examining this page could incorrectly assume that the code is executed.

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 delimiters.

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

Compliant Solution (Preprocessor)

Instead of using /* and */ to comment out blocks of code, use conditional compilation (for example, #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. 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.

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 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 (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

Remediation Cost

Priority

Level

MSC04-C

Medium

Unlikely

Medium

P4

L3

Automated Detection

Tool

Version

Checker

Description

Astrée
19.04

mmline-comment
smline-comment

smline-comment
sline-splicing

Partially checked
GCC
4.3.5

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

ECLAIR

1.2

CC2.MSC04

Fully implemented

LDRA tool suite
9.7.1
119 S, 302 S, 611 S

Partially implemented

Parasoft C/C++test
10.4.2

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

Polyspace Bug Finder

R2019a

CERT C: Rec. MSC04-C


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

PRQA QA-C
9.5
3108
RuleChecker
19.04

mmline-comment
smline-comment

smline-comment
sline-splicing

Partially checked

Related Vulnerabilities

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

Related Guidelines

Bibliography



3 Comments

  1. WHile I agree with the recommendation, comments have nothing to do with the preprocessor.  They are replaced by a space before preprocessing begins.

    1. OK, I'll move this to misc.

  2. Valuable info !!

    Agree with all the facts.

    Only The Fitness