[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

185.0. "Nested comments" by SMAUG::BELANGER (Quality is not a mistake!) Fri Jul 13 1990 19:19

    
    	The MCC_VEA_DEF.H file has a number of nested comments.  This
    causes the VAX C compiler (V3.1) to spit out a number of warnings
    (particularly when used with the /PORTABLE=STANDARD qualifier).
    I've editted my version of the .H file to not have this problem.
    Could this problem be removed from the files on the kit?
    
    Thanx,
    
    ~Jon.
T.RTitleUserPersonal
Name
DateLines
185.1passed alongGOSTE::CALLANDERMon Jul 16 1990 12:523
    
    Your request has been sent along to the team owning this file.
    
185.2TOOK::SWISTJim Swist LKG2-2/T2 DTN 226-7102Tue Jul 17 1990 00:4512
    We're going to clean some of this up when we port to Ultrix, but it's
    probably too late to do other than minor things for MCC v1.0/vms.
    
    With regard to the specific case cited, it should be noted that neither
    the VAX nor the MIPS Ultrix C compilers complain about nested comments
    (and the VAX/Ultrix pcc is generally regarded as a lowest common
    denominator).
    
    As a matter of general policy I'm not sure we should change something
    if ONLY the VAX C STANDARD=PORTABLE qualifier complains about it,
    particularly if ANSI C (where we're all supposed to be going) allows
    it.
185.3TOOK::R_LANETue Jul 17 1990 12:5013
I find the STANDARD=PORTABLE qualifier very useful for debugging coding
errors (including missing "*/", which results in "nested comment"
informational messages).  However, it usefulness is diminished somewhat if
the compiler output is cluttered with nested comment messages caused by
comments that contain an extra "/*".

C certainly allows the type of "nested comments" that are in mcc_vea_def.h,
but I think this is a bad practice that should be avoided, especially in
common header files that are used by many programmers.

The next time someone adds something to mcc_vea_def.h I think that an extra
5 minutes spent on removing the "/*" from within the comments is worth the
effort.
185.4Check Kernighan and Ritchie...SMAUG::BELANGERQuality is not a mistake!Tue Jul 17 1990 13:4312
    
    	In regard to nested comments and ANSI C.  According to Kernighan's
    and Ritchie's ANSI C book (usually considered the final word in ANSI
    C), on page 192 under the heading A2.2 Comments it states:
    
    	The characters /* introduce a comment, which terminates with 
    	the characters */.  Comments do not nest, and the do not occur
    	within string or character literals.
    
    Therefore, nested comments are NOT accepted by ANSI C.
    
    ~Jon.
185.5which is nested?TOOK::JESURAJTue Jul 17 1990 16:3837
    ref .-1
    
    
    Consider the examples:
    
     example A:
    
    
            /*
            /* 
            /*  */
    
     example B:
    
           /*
               /*
               */
            */
    
 Which one of these is nested?
    
    Clearly Example A follows the rule stated in .4 , and hence should be
    ok with the standard, and should not give any error message. 
    
    
    Example B does not follow the rule stated in .4. Therefore it should
    generate error message.
    
    
    The comments in MCC_VEA_DEF.H are  similar to example A above. I wonder
    why portable option gives error messages.
    
    
    ... jesuraj
    
    
    
185.6TOOK::R_LANEWed Jul 18 1990 16:1537
Re: .5

I think what is meant by the statement "comments do not nest" is that you
can't "comment out" a section of code that contains one or more comments.
It's clear that the comments in your example "B" are nested.

Why the comment in example "A" is considered to be a nested comment isn't
as clear because "/*" can be included in a comment intentionally by the
programmer without causing any problems during compilation.  The
compilation is successful because once the first "/*" is encountered, all
following characters (including the second "/*") are ignored until a "*/"
is found.

The following is also equivalent to your example "A":

        /* comment... programmer forgot to end comment

        <code>
          .
          .
          .

        /* next comment... */

I consider this to be a nested comment also.  This type of mistake can
sometimes cause subtle bugs that are hard to find.  I would rather
have the compiler issue a message warning me about a possible nested
comment than have to find the problem myself during a debugging session.

Compiler messages generated due to comments that intentionally contain "/*"
may obscure messages that indicate erroneous "open" comments.  This is why
I think it's a bad practice to use "/*" within comments, especially in
public header files.  There are plenty of other character combinations that
can be used as separators or "comment block borders".


Roy