[comp.lang.c] Nested Comments in C -- A recent experience

crds@pyrite.som.cwru.edu (Glenn A. Emelko) (03/11/90)

Well, for once in a long while I've got a few cents to throw in.  Just got done
spending 3 hours looking for a "bug" which turned out not to be a "bug" at all;
rather it went undetected as a programming error BECAUSE our C compiler doesn't
handle nested comments (like most C compilers don't).  The code looked like the
example below (not the actual code, but similar):

      function(arg1,arg2) {
        int a,b,c;
        a=arg1*arg2+3;     /* Oops, we're going to forget to close this comment
        b=arg1+2*arg2;     /* Guess what, this line never gets executed */
        c=a+b;
        return(c);         /* Here's the bogus results, Mr. caller */
      }

Unfortunately, we spent very little time suspecting that "function" didn't work
properly, because it was so simple!  The compiler didn't complain about it, and
we had no reason to suspect that it wasn't returning the proper value - in fact
when we looked at what it returned we STILL were baffled - so much in fact that
we decided to look at the .asm file to find the nasty stack corruption that had
to be causing our problem (or so we thought)... and that's where I noticed that
a whole line of code was missing in the .asm code; I did a double-take and then
looked REAL carefully at the C code and spotted the missing end-of-comment.  Up
until now I had no opinion on this matter; however things have changed.  If the
C compiler understood nested comments it would FORCE programmers to match them,
preventing wasted hours of debugging on annoying problems like the above at the
expense of a few milliseconds of additional compile time.  Anyone else?

Glenn Emelko

CMH117@psuvm.psu.edu (Charles Hannum) (03/11/90)

So.  Most Pascal compilers I've used would also choke if I forgot to close
a comment.  What about Ada?

P.S.  C++'s commenting method would avoid this problem entirely.


Virtually,
- Charles Martin Hannum II       "Klein bottle for sale ... inquire within."
    (That's Charles to you!)     "To life immortal!"
  cmh117@psuvm.{bitnet,psu.edu}  "No noozzzz izzz netzzzsnoozzzzz..."
  c9h@psuecl.{bitnet,psu.edu}    "Mem'ry, all alone in the moonlight ..."

tarvaine@tukki.jyu.fi (Tapani Tarvainen) (03/11/90)

In article <1990Mar11.065712.9798@usenet.ins.cwru.edu> crds@pyrite.som.cwru.edu (Glenn A. Emelko) writes:

>If the C compiler understood nested comments it would FORCE
>programmers to match them, preventing wasted hours of debugging on
>annoying problems like the above at the expense of a few milliseconds
>of additional compile time.

Turbo C has a compile-time switch for allowing nested comments.
The only use for it I've come up with so far is catching missing
comment delimiters:  If the program compiles differently with
the switch than without it, it's more than likely that a comment
delimiter has been omitted.




-- 
Tapani Tarvainen    (tarvaine@jyu.fi, tarvainen@finjyu.bitnet)

peter@ficc.uu.net (Peter da Silva) (03/11/90)

| Well, for once in a long while I've got a few cents to throw in.
| Just got done spending 3 hours looking for a "bug" which turned
| out not to be a "bug" at all; rather it went undetected as a
| programming error BECAUSE our C compiler doesn't handle nested
| comments (like most C compilers don't).

Alternatively, the problem was cause because the comment wasn't terminated
by the end of the line. I think a better fix than making comments nest would
be to add "// ... <eoln>" comments like C++ uses. Then in the next release
of the standard deprecate "/* ... */" comments.

This would also solve the old "a = *b/*c;" problem as well.

Nested comments are a fertile source of potential bugs. I'm not going to
rehash the old "comment seperator in string vs. commented-out code" argument.
Just sit down and think of the ramifications a little while...
-- 
 _--_|\  `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/      \  'U`
\_.--._/
      v

dave@cs.arizona.edu (David P. Schaumann) (03/12/90)

In article <1990Mar11.065712.9798@usenet.ins.cwru.edu>, crds@pyrite.som.cwru.edu (Glenn A. Emelko) writes:
|Well, for once in a long while I've got a few cents to throw in. Just got
|done spending 3 hours looking for a "bug" which turned out not to be a "bug"
							    ^^^^^^^^^^^^^^^^^
|at all; rather it went undetected as a programming error BECAUSE our C
					^^^^^^^^^^^^^^^^^
What's the difference?

|compiler doesn't handle nested comments (like most C compilers don't).  The
|code looked like the example below (not the actual code, but similar):
|
|      function(arg1,arg2) {
|        int a,b,c;
|        a=arg1*arg2+3;    /* Oops, we're going to forget to close this comment
|        b=arg1+2*arg2;     /* Guess what, this line never gets executed */
|        c=a+b;
|        return(c);         /* Here's the bogus results, Mr. caller */
|      }

  [ description of search for bug deleted ]

|If the C compiler understood nested comments it would FORCE programmers to
|match them, preventing wasted hours of debugging on annoying problems like
|the above at the expense of a few milliseconds of additional compile time.
|
|Glenn Emelko

The C compiler here (gcc) has an option which will warn of a comment start
sequence (/*) embedded in a comment.  I agree that this should have been
caught by the compiler, but I think adding nested comments is the wrong
solution.  Rather, the compiler should always flag the occurance of /*
within a comment unless explicitly told to shut up about it.  Does anyone know
what ANSI says about this?

Dave Schaumann
dave@cs.arizona.edu

henry@utzoo.uucp (Henry Spencer) (03/12/90)

In article <1990Mar11.065712.9798@usenet.ins.cwru.edu> crds@pyrite.som.cwru.edu (Glenn A. Emelko) writes:
>... 3 hours looking for a "bug" which turned out not to be a "bug" at all;
>rather it went undetected as a programming error BECAUSE our C compiler doesn't
>handle nested comments (like most C compilers don't)...

You mean "because our C compiler doesn't issue a warning when it sees /*
inside a comment".  C COMMENTS DO NOT NEST.  THEY NEVER HAVE.  ANY COMPILER
WHICH "HANDLES" NESTED COMMENTS IS NOT A C COMPILER.  It is legitimate to
complain about a compiler which doesn't flag /* in a comment as a possible
error, but claiming that a C compiler should "handle nested comments" is
just silly; no C compiler can do that.
-- 
MSDOS, abbrev:  Maybe SomeDay |     Henry Spencer at U of Toronto Zoology
an Operating System.          | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

trt@rti.UUCP (Thomas Truscott) (03/12/90)

Besides failing to issue a warning about the comment,
the compiler also failed to notice that "b" was used before set.
(Lint would have warned about that.)

So you gave the compiler two chances, and it blew them both.

henry@utzoo.uucp (Henry Spencer) (03/13/90)

In article <133@caslon.cs.arizona.edu> dave@cs.arizona.edu (David P. Schaumann) writes:
>... I think adding nested comments is the wrong
>solution.  Rather, the compiler should always flag the occurance of /*
>within a comment unless explicitly told to shut up about it.  Does anyone know
>what ANSI says about this?

ANSI C (draft of Oct 88) says -- as all C definitions have always said --
that comments do not nest.  Detection of /* within a comment is mentioned
as a "common warning", which is about the strongest thing the standard
can say about it since the standard does not address what diagnostics a
compiler produces.
-- 
MSDOS, abbrev:  Maybe SomeDay |     Henry Spencer at U of Toronto Zoology
an Operating System.          | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

adrian@mti.mti.com (Adrian McCarthy) (03/13/90)

A nice compiler should warn about "/*" inside of a comment by default.  (Of
course the user should be able to deactivate this warning if he/she so
desires.)

The experience recently posted could have been caught with lint or a
coverage analyzer or even a debugger in a pretty short amount of time.

I'm not so hot on C++'s comment to end-of-line scheme because I often find
myself in situations where I want to put a comment in the middle of a line
of code.  For example:

  int table [3][3] =
    {        /*  0,  1,  2 */
      /* 0 */ { 99, 42, 37},
      /* 1 */ { 13, 12, 11},
      /* 2 */ { 55, 56, 57}
    };

or:

  (void) memcpy(/*targ*/ (void *) &x, /*src*/ (void *) &y, sizeof(y));

I too want something like nesting, so that I can comment out chunks of code
rather than #ifdef'ing.  But I agree that nested comments are not the answer.
Instead I'd like to see two types of comment delimiters (like Pascal), with
the restriction that "/*" comments can only be closed by "*/" and that
"@@" (or whatever) can only be closed by "@@".  If you use the standard
comments consistenly for regular types of commenting, and the alternate
form for commenting out code, then almost everyone should be happy.  In fact,
the alternate form could be the C++ scheme of "//" to end-of-line, which is
very appropriate for trying to comment out chunks of code.

Aid.

bright@Data-IO.COM (Walter Bright) (03/13/90)

In article <1990Mar11.065712.9798@usenet.ins.cwru.edu> crds@pyrite.som.cwru.edu (Glenn A. Emelko) writes:
<Just got done
<spending 3 hours looking for a "bug" which turned out not to be a "bug" at all;
<rather it went undetected as a programming error BECAUSE our C compiler doesn't
<handle nested comments (like most C compilers don't).
<      function(arg1,arg2) {
<        int a,b,c;
<        a=arg1*arg2+3;     /* Oops, we're going to forget to close this comment
<        b=arg1+2*arg2;     /* Guess what, this line never gets executed */
<        c=a+b;
<        return(c);         /* Here's the bogus results, Mr. caller */
<      }

I sympathize, I had exactly this problem once. Whereupon I modified my
compiler to produce the message:

        b=arg1+2*arg2;     /* Guess what, this line never gets executed */
			    ^
	Warning: nested comments are not allowed

which eliminated the problem.

jharkins@sagpd1.UUCP (Jim Harkins) (03/13/90)

In article <1990Mar11.065712.9798@usenet.ins.cwru.edu> crds@pyrite.som.cwru.edu (Glenn A. Emelko) writes:
#Well, for once in a long while I've got a few cents to throw in.  Just got done
#spending 3 hours looking for a "bug" which turned out not to be a "bug" at all;
#rather it went undetected as a programming error BECAUSE our C compiler doesn't
#handle nested comments (like most C compilers don't).  The code looked like the
#example below (not the actual code, but similar):
#
#      function(arg1,arg2) {
#        int a,b,c;
#        a=arg1*arg2+3;     /* Oops, we're going to forget to close this comment
#        b=arg1+2*arg2;     /* Guess what, this line never gets executed */
#        c=a+b;
#        return(c);         /* Here's the bogus results, Mr. caller */
#      }
#
#Unfortunately, we spent very little time suspecting that "function" didn't work
#properly, because it was so simple!

Sorry Charlie, but if part of your testing doesn't involve testing each low-
level function individually, especially the "simple" ones, you have much more
serious problems to worry about than nested comments.


-- 
jim		jharkins@sagpd1

"My hope is that we can use tariffs to force Japan to open their markets to
 imported goods.  My fear is I'll be forced to buy lousy American made stuff."

msau@wpi.wpi.edu (Matt Saucier) (03/13/90)

IMO, a source level debugger is great for spotting problems like this...
"Whoops - it skipped a statement - Oh, I don't believe it... I forgot to close
the comment!"  Anyways, I've had similar problems, but, like someone else
mentioned - some compilers yell about a variable being used before it was
given a value.

To Mr HS.  If you say that C compilers that allow, or can allow, nested
comments are not C compilers, then you are very nieve.  There are times,
in which nested comments are a plus; Although I don't use the nested comment
method (I use #ifdef DEBUG #endif (or whatever)), I know a lot of people who
do use them.  They use TurboC.  And if you don't call that a C compiler,
maybe you should open your eyes.  TC has an option to turn on nested comments;
it's default is no nested comments.  Yes, if the option is on, it is not
technically, ANSI (nor K&R) C.  But who EVER ports C code while debugging?
I don't think ANYONE would be foolish enough to leave nested comments in
a completed, running program (actually, I could be wrong, but they are very
foolish indeed)  Nested comments, IMHO, are provided as an option for those
who have a certian style of debugging.  Just because a compiler offers an
extra FEATURE doesn't mean that it's not a C compiler - it's just helpful.


-- 
Internet: msau@wpi.wpi.edu     \\  Koyannisqatsi: n.  1. crazy life  2. life in
  BITNET: msau@wpi.bitnet        \\  turmoil  3. life disintegrating  4. life
    UUCP: uunet!wpi.wpi.edu!msau   \\  out of balance  5. a state of life that
Compuserve: 72371,3101  WPI BOX 1346 \\  calls for another way of living.

gary@hpavla.AVO.HP.COM (Gary Jackoway) (03/13/90)

>  (void) memcpy(/*targ*/ (void *) &x, /*src*/ (void *) &y, sizeof(y));

Aid.
----------
Can anyone actual understand this line?  I find imbedded comments
like this a nuisance.  Wouldn't

//	           target:      source:
    (void) memcpy((void *) &x, (void *) &y, sizeof(y));

be more readable?

Or maybe:

/*  Copy y into x	*/
    (void) memcpy((void *) &x, (void *) &y, sizeof(y));

Just a thought.
Gary Jackoway

ado@elsie.UUCP (Arthur David Olson) (03/13/90)

> ANSI C (draft of Oct 88) says...that comments do not nest.
> Detection of /* within a comment is mentioned as a "common warning"...

The "comments do not nest" statement is in a footnote;
the /* "common warning" statement is in an appendix;
neither is part of the ANSI standard.
-- 
	Arthur David Olson   ado@alw.nih.gov   ADO is a trademark of Ampex.

jsulliva@cvbnet.UUCP (Jeff Sullivan, x4096 MS 4-2) (03/14/90)

   I have used at least one C compiler that allowed nested comments
 with the use of a command line flag. The default was to not allow
 them. I thought this was great for debugging since I could "comment
 out" large blocks of code, comments and all. This was the only benefit
 I could see in allowing nested comments.

   Anyway, since then I have used #define's to comment out large blocks
 of code (while debugging). For example:

#ifdef disabled
  statement1;	/* comment 1  */
     ....
  statementn;   /* comment n */
#endif

 Obviously, you never #define disabled.
 Works fo me!

 -Jeff
  

buck@siswat.UUCP (A. Lester Buck) (03/14/90)

In article <1990Mar11.065712.9798@usenet.ins.cwru.edu> crds@pyrite.som.cwru.edu (Glenn A. Emelko) writes:
>If the C compiler understood nested comments it would FORCE
>programmers to match them, preventing wasted hours of debugging on
>annoying problems like the above at the expense of a few milliseconds
>of additional compile time.

Try the lint helper programs at uunet!~/nutshell/lint/* as described in
the Nutshell handbook on lint.

These programs include:

cchk - cchk check C programs for correctly matching brackets of all kinds
(including quotes and comment brackets), checks that the indentation of
matching brackets also matches, and checks for symptoms of three kinds of
errors that the C compiler allows without warning: 'dangling else' errors
where an else is bound to the wrong preceding if, nested comments (where
the first close-comment bracket prematurely ends the outer comment), and
the use of assigment ('=') where equality-test ('==') was meant.  It is
faster than the compiler and produces better messages; in particular,
it localizes bracketing problems much more accurately.

cchk was written by Steve Draper at Berkeley.


-- 
A. Lester Buck     buck@siswat.lonestar.org  ...!texbell!moray!siswat!buck

will@kfw.COM (Will Crowder) (03/15/90)

In article <90150@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes:
>> ANSI C (draft of Oct 88) says...that comments do not nest.
>> Detection of /* within a comment is mentioned as a "common warning"...
>
>The "comments do not nest" statement is in a footnote;
>the /* "common warning" statement is in an appendix;
>neither is part of the ANSI standard.

The fact that the statement "comments do not nest" is in a footnote does
indeed mean that that statement is not part of the Standard.  However,
the Standard does contain explicit language indicating that comments
do not nest.

The verbiage:

Section 3.1.9 Comments:

	Except within a character constant, a string literal, *or a comment*,
the characters /* introduce a comment.  The contents of a comment are 
examined only to identify multibyte characters and find the characters
*/ that terminate it.

December 7, 1988 Draft ANSI Standard for the 'C' Programming Language

[emphasis added]

Now I don't know about the rest of you net.folks out there, but haven't
we hashed this around *quite enough* by now?  Face it, comments do *not*
nest in the 'C' language, never have, and probably never will.  This does
not introduce, in my opinion, any more problems than would allowing comments
to nest.  It is simply a fact of the language, and is probably not worth
any more net.bandwidth.  I have directed this article to comp.lang.c instead
of the poster, because there are apparently quite a few folks out there
who can't deal with these facts.  Followups to /dev/null... 

>-- 
>	Arthur David Olson   ado@alw.nih.gov   ADO is a trademark of Ampex.

Will

bright@Data-IO.COM (Walter Bright) (03/15/90)

In article <9130008@hpavla.AVO.HP.COM> gary@hpavla.AVO.HP.COM (Gary Jackoway) writes:
<<  (void) memcpy(/*targ*/ (void *) &x, /*src*/ (void *) &y, sizeof(y));
<Wouldn't
<//	           target:      source:
<    (void) memcpy((void *) &x, (void *) &y, sizeof(y));
<be more readable? Or maybe:
</*  Copy y into x	*/
<    (void) memcpy((void *) &x, (void *) &y, sizeof(y));

It's more readable if you eliminate the redundant clutter:
	memcpy(&x,&y,sizeof(y));	/* Copy y into x	*/

jeffa@hpmwtd.HP.COM (Jeff Aguilera) (03/16/90)

>	memcpy(&x,&y,sizeof(y));	/* Copy y into x	*/

But that comment is completely superfluous and totally redundant :-)  Why not

	memcpy(&x,&y,sizeof(y));	/* RTFM */

or

	memcpy(&x,&y,sizeof(y)); //use: <string.h>

-----
jeffa

djones@megatest.UUCP (Dave Jones) (03/17/90)

From article <2381@dataio.Data-IO.COM>, by bright@Data-IO.COM (Walter Bright):
> In article <9130008@hpavla.AVO.HP.COM> gary@hpavla.AVO.HP.COM (Gary Jackoway) writes:
> <<  (void) memcpy(/*targ*/ (void *) &x, /*src*/ (void *) &y, sizeof(y));
> <Wouldn't
> <//	           target:      source:
> <    (void) memcpy((void *) &x, (void *) &y, sizeof(y));
> <be more readable? Or maybe:
> </*  Copy y into x	*/
> <    (void) memcpy((void *) &x, (void *) &y, sizeof(y));
> 
> It's more readable if you eliminate the redundant clutter:
> 	memcpy(&x,&y,sizeof(y));	/* Copy y into x	*/


Strictly speaking, you have to keep the (void*) casts, just in case some
enemy system codes some kinds of pointers in screwy ways. It can happen.

So we got this:

   memcpy((void*)&x,(void*)&y,sizeof(y));   /* Copy y into x  */

Not too bad.

If I had my way, the C++ style out-to-the-end-of-the-line comment would
be the only kind available.


     //  Know what I mean, Bean?


But then, if I had my way, I wouldn't be programming now would I? I would
have WAY to much money to bother with work.

As it is, I use only two styles:


/*
 * Block comments
 * that can go on and on...
 */

... and ...

 /* ... out to end of line comments. */

The reason I don't do blocks ...

/*  ... like a bunch */
/*  of out to end */
/*  of line comments... */

... is that blocks like that are too hard to edit, especially if you
like to ...

/* ... line up the   */
/* comment-ends      */
/* nice and tidy.    */

Rarely, I do want to put comments on actual parameters, as in the
original memcpy example. I still use the o-t-e-o-l comment:

     memcpy( (void*)&y,     /* target */
             (void*)&x,     /* source */
             sizeof(y)
           );

I guess KR indentation purists would do this:

     memcpy( 
       (void*)&y,     /* target */
       (void*)&x,     /* source */
       sizeof(y)
     );

Nah, maybe not.

One of the most affected comment styles that I have seen inflicted on the
innocent code-reading public had all the comments on the left! Made me
just want to take the guy and shake him.

/*  It all looked */   main(argv, argc)
/*  really weird, */      char** argv;
/*  even pompous, */   {
/*  you know what */      printf("Goodbye, cruel world.\n");
/*  I mean, Bean? */   }

henry@utzoo.uucp (Henry Spencer) (03/18/90)

In article <9631@wpi.wpi.edu> msau@wpi.wpi.edu (Matt Saucier) writes:
>To Mr HS.  If you say that C compilers that allow, or can allow, nested
>comments are not C compilers, then you are very nieve...

I guess I'm just old-fashioned:  I feel that to be called a C compiler,
it should compile C.  Every definition of C, from the earliest days,
has been explicit that C comments do not nest.

>... Although I don't use the nested comment
>method (I use #ifdef DEBUG #endif (or whatever)), I know a lot of people who
>do use them....

As has been explained at length, several times, this is a thoroughly bad
idea that programmers eventually learn to avoid.  It simply doesn't work
as well as #ifdef.
-- 
MSDOS, abbrev:  Maybe SomeDay |     Henry Spencer at U of Toronto Zoology
an Operating System.          | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

ts@cup.portal.com (Tim W Smith) (03/18/90)

How about

	memcpy(
		&x,		/* destination */
		&y,		/* source */
		sizeof(x)	/* count */
	);

Of course, this will lead to arguments about how the parens shoudl go,
e.g.,

	memcpy
	(
		...
	)

vs.

	memcpy
		(
			...
		)

etc. :-)

					Tim Smith

ok@goanna.oz.au (Richard O'keefe) (03/19/90)

In article <9631@wpi.wpi.edu>, msau@wpi.wpi.edu (Matt Saucier) writes:
> But who EVER ports C code while debugging?

Anybody in his or her right mind who has the opportunity.
The right time to make your code portable is when you are writing it
the first time, and a lot of bugs (like, dare I say it, 0/nil problems
and of course dereferencing nil) tend to show up on one system but not
another.  Don't forget, different compilers tend to be picky about
different things.

> I don't think ANYONE would be foolish enough to leave nested comments in
> a completed, running program.
So trusting...  I have a bridge you might be interested in...
> Just because a compiler offers an
> extra FEATURE doesn't mean that it's not a C compiler - it's just helpful.

The point is that in the mode where it supports this "feature" the language
it is compiling is not C.  Such a compiler may have a mode in which the
language it compiles _IS_ C and in _that_ mode it is a C compiler.

bright@Data-IO.COM (Walter Bright) (03/20/90)

In article <12351@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes:
<From article <2381@dataio.Data-IO.COM>, by bright@Data-IO.COM (Walter Bright):
<< <    (void) memcpy((void *) &x, (void *) &y, sizeof(y));
<< It's more readable if you eliminate the redundant clutter:
<< 	memcpy(&x,&y,sizeof(y));	/* Copy y into x	*/
<Strictly speaking, you have to keep the (void*) casts, just in case some
<enemy system codes some kinds of pointers in screwy ways. It can happen.

Not so. If memcpy is prototyped properly, the (void*) casts will be
inserted automagically by the compiler.

dfoster@jarthur.Claremont.EDU (Derek R. Foster) (03/26/90)

In article <1990Mar18.045238.18224@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <9631@wpi.wpi.edu> msau@wpi.wpi.edu (Matt Saucier) writes:
>>... Although I don't use the nested comment
>>method (I use #ifdef DEBUG #endif (or whatever)), I know a lot of people who
>>do use them....
>
>As has been explained at length, several times, this is a thoroughly bad
>idea that programmers eventually learn to avoid.  It simply doesn't work
                                                   ^^^^^^^^^^^^^^^^^^^^^^
>as well as #ifdef.
 ^^^^^^^^^^^^^^^^^

You forgot to add "IN MY HUMBLE (or maybe not so humble, considering the
above statement) OPINION!" I have been using nested comments as debugging
tools for many years, and I have NEVER had a problem with them. The only
problem I have had is with people like you telling me I SHOULD have
problems with them, and telling me I shouldn't use them because YOU
think I'll have problems with them. (Which has not happened yet.)
I HAVE had problems with #ifdef and #endif -- they're a lot more trouble
to use when what I'm debugging is not a completely separate line. Not
to mention that I can't have my editor jump to matching #ifdef and #endif
pairs, regardless of nesting, like I can with /* and */ (I just position
the cursor, press ctrl-q-[, and it finds the matching /* or */) All in all,
when I hear you telling me "it simply doesn't work as well", and I consider
my own experiences with the above facts, my first inclination is to laugh
in your face. I have saved myself a TREMENDOUS amount of time by not using
#ifdef and #endif when I don't think they are necessary. You may think nested
comments aren't worth the trouble, but that's just YOUR OPINION. Say "_I_ 
haven't found it as easy to use, and _I_ think #ifdef and #endif are bettter"
Other people may have had different experiences. 

>MSDOS, abbrev:  Maybe SomeDay |     Henry Spencer at U of Toronto Zoology
>an Operating System.          | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

Derek Riippa Foster

karl@haddock.ima.isc.com (Karl Heuer) (03/26/90)

In article <5418@jarthur.Claremont.EDU> dfoster@jarthur.Claremont.EDU (Derek R. Foster) writes:
>In article <1990Mar18.045238.18224@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>>As has been explained at length, several times, this is a thoroughly bad
>>idea that programmers eventually learn to avoid.  It simply doesn't work
>>as well as #ifdef.
>
>You forgot to add "IN MY HUMBLE (or maybe not so humble, considering the
>above statement) OPINION!"

FACT: any modern C compiler will support #if...#endif, whereas comment nesting
is a local hack that happens to work on YOUR compiler.  In this sense, at
least, #if...#endif is a better choice.

Now, GIVEN that you like to program in a dialect that supports both
#if...#endif and comment nesting, and that you don't care about porting code
containing nested comments to Standard C, I suppose it's a matter of opinion
which one works better.

My OPINION is that #if...#endif is still a better choice, since it avoids
having to worry about how the local dialect handles quote-and-comment mixing,
and since it allows me to specify a condition to enable/disable the section of
code without having to edit the program source.

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint

bengsig@oracle.nl (Bjorn Engsig) (03/26/90)

Article <5418@jarthur.Claremont.EDU> by dfoster@jarthur.Claremont.EDU (Derek R. Foster) says:
|...  I have been using nested comments as debugging
|tools for many years, ....
If that is the case, may I then ask you why you post this message to
comp.lang.c?  "Nested comments" IMPLIES "Programming language is not C",
as been told here a zillion times.
-- 
Bjorn Engsig,	Domain:		bengsig@oracle.nl, bengsig@oracle.com
		Path:		uunet!mcsun!orcenl!bengsig

jenkins@jpl-devvax.JPL.NASA.GOV (Steve Jenkins) (03/26/90)

In article <5418@jarthur.Claremont.EDU> dfoster@jarthur.Claremont.EDU (Derek R. Foster) writes:
>[yak yak yak]
>You may think nested
>comments aren't worth the trouble, but that's just YOUR OPINION. Say "_I_ 
>haven't found it as easy to use, and _I_ think #ifdef and #endif are bettter"
>Other people may have had different experiences. 
>
>Derek Riippa Foster

Not with C, they haven't.  Regardless of Turbo-Pseudo-C,

		Comments do not nest [....]
					    K&R2, Section A2.2.

-- 
Steve Jenkins N6UNI			jenkins@jpl-devvax.jpl.nasa.gov
Caltech/Jet Propulsion Laboratory	(818) 354-0162

dfoster@jarthur.Claremont.EDU (Derek R. Foster) (03/28/90)

In article <581@nlsun1.oracle.nl> bengsig@oracle.nl (Bjorn Engsig) writes:
>Article <5418@jarthur.Claremont.EDU> by dfoster@jarthur.Claremont.EDU (Derek R. Foster) says:
>|...  I have been using nested comments as debugging
>|tools for many years, ....
>If that is the case, may I then ask you why you post this message to
>comp.lang.c?  "Nested comments" IMPLIES "Programming language is not C",
>as been told here a zillion times.

Because by the time I release anything to anybody but myself, I have
removed the nested comments, and it IS C. This "Programming languages
that include nested comments aren't C" argument is a non-sequitur that,
although TECHNICALLY true, had no relevance to the discussion when
it was first stated. Guess what? It still isn't relevant. I don't hear
about anybody claiming that languages which support typeof() or __handle
pointers, or other extensions that don't appear in the standard are "not C"
Instead, they are "Dialects of C". In fact, every compiler that I am aware
of is nonstandard in at least some minor point. The standards
committee often refuses to add new capabilities to the standard unless
someone has tried them out first. By your definition, MOST of the people who
post here aren't writing in C, and anyone who submits a program or a
question which uses even ONE nonstandard feature shouldn't post. In fact,
even people who are using outdated compilers shouldn't post, since the
new standard implies that their programs are "not C", even if they were
when written. (Where should these people go, by the way? In the heat of
sarcasm, you failed to mention that information.) This is obviously
ridiculous. Nested comments are no different. They are FEATURES of some
DIALECTS of C. You will note that this newsgroup is not "comp.std.c." It
is "comp.lang.c" If you don't like nested comments, at least try to find
a better argument against them than this.

Derek Riippa Foster

flaps@dgp.toronto.edu (Alan J Rosenthal) (03/28/90)

dfoster@jarthur.Claremont.EDU (Derek R. Foster) writes:
>I don't hear about anybody claiming that languages which support typeof() or
>__handle pointers, or other extensions that don't appear in the standard are
>"not C".  Instead, they are "Dialects of C".

Creating a keyword `__handle' is backward-compatible with C, in the sense that
all correct C programs will continue to exhibit the same behaviour (because
user identifiers may not begin with `__').

Adding `typeof' is almost backward-compatible, and will work so long as this
identifier is not otherwise used.  It should have been `__typeof'.

Adding that nested comments idea will probably break about 10 or 15 per cent of
all programs with a non-trivial maintenance history.  It is not C.  Also, none
of these other changes are lexical-level changes.

ajr

--
"Learning algorithms from Knuth is almost as bad as learning physics from
 Newton in the Latin original."                     -- Jeffrey Kegler

henry@utzoo.uucp (Henry Spencer) (03/28/90)

In article <5418@jarthur.Claremont.EDU> dfoster@jarthur.Claremont.EDU (Derek R. Foster) writes:
>>As has been explained at length, several times, this is a thoroughly bad
>>idea that programmers eventually learn to avoid.  It simply doesn't work
>>as well as #ifdef.
>
>You forgot to add "IN MY HUMBLE (or maybe not so humble, considering the
>above statement) OPINION!"

Me, humble?  I was humble once in 1962; I didn't like it and haven't
repeated it. :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)

>I have been using nested comments as debugging
>tools for many years, and I have NEVER had a problem with them.

Obviously you never ran into a string containing /*, or the deliberately
mismatched comments used for configuration options in some software packages
and for debugging by some programmers.  As has been explained before, the
stuff inside a comment loses all token structure, which makes it much
easier to encounter "accidental" comment delimiters.  As has been explained
before, because nested comments are not standard C, you can expect to find
code that relies on comments not nesting.  #ifdef has neither problem, and
is also rather more conspicuous when somebody else has to read your code.

>I HAVE had problems with #ifdef and #endif -- they're a lot more trouble
>to use when what I'm debugging is not a completely separate line.

If it's not a completely separate line, it's not likely to have comments
inside it, so regular non-nested comments will suffice.

>Not
>to mention that I can't have my editor jump to matching #ifdef and #endif
>pairs, regardless of nesting, like I can with /* and */ ...

Perhaps you should get a better editor?  They do exist.
-- 
Apollo @ 8yrs: one small step.|     Henry Spencer at U of Toronto Zoology
Space station @ 8yrs:        .| uunet!attcan!utzoo!henry henry@zoo.toronto.edu

dms@cs.arizona.edu (David Michael Shackelford) (04/07/90)

In article <1060001@hparc0.HP.COM>, graham@hparc0.HP.COM (Graham Eddy) writes:
> In my _humble_ opinion, I would like to be given a list of the
> C compilers that suport the non-standard feature of nested comments.
> As a previous item noted, it would break the majority of portable
> code, and I want to know which compilers to avoid.

Since everyone is saying that nested comments are *non-standard*, why would
a compiler's inclusion of the nested comment feature break programs?  How
can this break a program which doesn't contain any nested comments? I'm
not advocating the use of this feature, but IMHO an "extension" must have
some potential use, or the compiler wouldn't have it.   

Dave    | dms@cs.arizona.edu        

peter@ficc.uu.net (Peter da Silva) (04/07/90)

In article <207@caslon.cs.arizona.edu> dms@cs.arizona.edu (David Michael Shackelford) writes:
> Since everyone is saying that nested comments are *non-standard*, why would
> a compiler's inclusion of the nested comment feature break programs?

From B News source, file "defs.h". Consider what this code looks like
to the compiler if comments nest:

				/* Default xmit command - remove -z if	*/
#define DFTXMIT	"uux - -r -n %s!rnews < %s" /* your uux can't do it	*/
/* #define UXMIT	"uux -r -z -c %s!rnews '<' %s" /* If uux -c is ok	*/
#define DFTEDITOR "aed"		/* Default editor, see also postnews.	*/
/* #define UUPROG "euuname"	/* omit for uuname, put in LIBDIR	*/
#define MANUALLY		/* Don't execute rmgroups, just notify.	*/
#define NONEWGROUPS		/* Don't create new groups, just notify.*/
/* #define SPOOLNEWS		/* Spool incoming rnews, don't process	*/
/* #define SPOOLINEWS		/* Spool local inews, don't process	*/
/* #define LOCALNAME 		/* There is no full name database. 	*/
-- 
 _--_|\  `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/      \  'U`
\_.--._/
      v