dougp@voodoo.ucsb.edu (10/05/89)
-Message-Text-Follows-
main()
{
int a=1,b=2,*p=&a,c;
c=b/*p;
}
First real flaw in the C grammer I have found.fredex@cg-atla.UUCP (Fred Smith) (10/05/89)
In article <2432@hub.UUCP> dougp@voodoo.ucsb.edu writes: >-Message-Text-Follows- >main() > { > int a=1,b=2,*p=&a,c; > c=b/*p; > } > >First real flaw in the C grammer I have found. FLAME ON: Just because C allows you to write terse, dense code, doesn't mean you should actually DO it! A much better (not to mention, more readable) way to write that would be: c = b / *p; or alternatively: c = b / (*p); With the second one you can leave out the spaces, which is your wont, even though I think that it is easier to read with spaces around the operators and sub-expressions. FLAME OFF: Fred
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/05/89)
In article <2432@hub.UUCP> dougp@voodoo.ucsb.edu writes: > c=b/*p; So, did you learn your lesson and start using whitespace?
dwb@sppy00.UUCP (David Burhans) (10/05/89)
In article <2432@hub.UUCP> dougp@voodoo.ucsb.edu writes: 1> main() 2> { 3> int a=1,b=2,*p=&a,c; 4> c=b/*p; 5> } > > First real flaw in the C grammer I have found. This is not a flaw in the C grammer, it is a flaw in the c programmer. Don't expect a compiler to second guess you. Line 4 contains an assignment and the start of a comment. As there is no end of comment, you should get an error message along the lines of ``unterminated comment.'' Try the following: c = b / *p; White space not only solves your problem, it makes your code more readable. Also, in line 3 you have an illegal compination of an int * and an int. Once again, white space solves your problem. -DwB -- dwb@sppy00 {att|killer|pyramid}!osu-cis!sppy00!dwb David Burhans/6565 Frantz Rd./Columbus, Oh 43017 **** Views expressed above were randomly generated with a six sided die and as such are not the views of my employer. *****
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/05/89)
In article <2432@hub.UUCP>, dougp@voodoo.ucsb.edu writes: | int a=1,b=2,*p=&a,c; | c=b/*p; | | First real flaw in the C grammer I have found. This is a good example, and I thank you. I have added something similar to my list of things to think about in the pointers section of my C course notes. It pops up in macros from time to time. Consider: #define xavg(m) (sum+3)/m Macros like this work fine until someone makes the arg a pointer deref, in which case the compiler screams and the programmer can't see the error. It's even worse if someone makes a mistake like this in a system header file... Kruft = xavg(*misc_err)+2; or even worse Kruft = xavg(*misc_err)+2 /* ruft constant */; which gives no warning but a wrong answer. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
dowell@metaphor.Metaphor.COM (Craig Dowell) (10/06/89)
References: <2432@hub.UUCP> In article <2432@hub.UUCP>, dougp@voodoo.ucsb.edu writes: > -Message-Text-Follows- > main() > { > int a=1,b=2,*p=&a,c; > c=b/*p; > } > > First real flaw in the C grammer I have found.
peper1@unix.cis.pitt.edu (J. Christian A. Peper) (10/06/89)
In article <2432@hub.UUCP> dougp@voodoo.ucsb.edu writes: >main() > { > int a=1,b=2,*p=&a,c; > c=b/*p; > } >First real flaw in the C grammer I have found. Why? What's wrong with it? *p is an integer ptr, right? So? c = 2 Chris. -- * PEPER1@PITTVMS.BITNET peper1@unix.cis.pitt.edu * * Claimer: If it ain't DUTCH, it ain't much!!!!!! * * En voor jullie eikels daar ergens: Net goed!! Toffelemoon! *
john@frog.UUCP (John Woods) (10/06/89)
In article <2432@hub.UUCP>, dougp@voodoo.ucsb.edu writes: > -Message-Text-Follows- < main() > { < int a=1,b=2,*p=&a,c; > c=b/*p; < } > First real flaw in the C grammer I have found. usespacestheymakeyourcodemuchmorereadableandhappentoavoidthisproblemasa pleasantsideeffectparentheseswouldalsobehandysincepunctuationcanbeyourfriend -- John Woods, Charles River Data Systems, Framingham MA 508-626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu
dougp@voodoo.ucsb.edu (10/06/89)
-Message-Text-Follows- In article <7734@cg-atla.UUCP>, fredex@cg-atla.UUCP (Fred Smith) writes... >FLAME ON: > >Just because C allows you to write terse, dense code, doesn't mean you should >actually DO it! > >A much better (not to mention, more readable) way to write that would be: >FLAME OFF: > > >Fred FLAME ON: Fred, you are a twit for flaming me on a matter of prefeference. FLAME OFF: I was pointing out a flaw in the grammer of C not pushing any style of code. I happen to find that equations with no spaces are easier to read. If you don't like that, DON'T READ MY CODE. The real point of my message was that /* was a bad choice for the opening of a comment because it can appear in normal code and not be intended to be the start of a comment. You can have a**p, a+*p, a-*p but not a/*p this is an inconsistancy in the grammar. This wouldn't have been so bad but for a bug in the Microsoft C compiler such that: // c=a/*p; e=f*q; /*comment*/ causes the statment e=f*p; to be commented out. the /* in the line commented out by // is seen as the beginning of the comment. This made localizing the error an hour job. Douglas Peale
norm@oglvee.UUCP (Norman Joseph) (10/06/89)
From article <2432@hub.UUCP>, by dougp@voodoo.ucsb.edu: > -Message-Text-Follows- > main() > { > int a=1,b=2,*p=&a,c; > c=b/*p; > } > > First real flaw in the C grammer I have found. I think it's just as fair to say that the fault lies not in the Grammar but in the Programmer (with apologies to Shakespeare). Not only would the judicious use of white space have prevented this "flaw", but it makes good sense for readability & maintenance. What makes people afraid to hit the space bar? Is it sloth, or ignorance? -- Norm Joseph - Oglevee Computer System, Inc. UUCP: ...!{pitt,cgh}!amanue!oglvee!norm /* you are not expected to understand this */
smk@cbnews.ATT.COM (Stephen M. Kennedy) (10/06/89)
In article <832@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: > This is a good example, and I thank you. I have added something >similar to my list of things to think about in the pointers section of >my C course notes. > It pops up in macros from time to time. Consider: > #define xavg(m) (sum+3)/m Why did you put this in the pointers section? This is just a poorly parenthesized macro. Consider "y = 1 / xavag(10);" or "xavg(n * 10)". p.s. In another article, did someone say it was ok to define an abs macro as -(x)? What about "y = -abs(x);"? --- Steve Kennedy att!cbosgd!smk "I love you, Kate"
scott@bbxsda.UUCP (Scott Amspoker) (10/06/89)
In article <2432@hub.UUCP> dougp@voodoo.ucsb.edu writes:
1> main()
2> {
3> int a=1,b=2,*p=&a,c;
^^
4> c=b/*p;
5> }
Some C compilers will also give you a warning about "=&" which is
the "old-style" way of saying "&=".
--
Scott Amspoker
Basis International, Albuquerque, NM
(505) 345-5232ray@philmtl.philips.ca (Ray Dunn) (10/07/89)
In article <568@sppy00.UUCP> dwb@sppy00.UUCP (David Burhans) writes: >In article <2432@hub.UUCP> dougp@voodoo.ucsb.edu writes: >4> c=b/*p; > > First real flaw in the C grammer I have found. > >This is not a flaw in the C grammer, it is a flaw in the c programmer. This, as we all know by now of course, is a matter of religion. So let me restate the principles of *my* sect: No this *is* a flaw in the C grammer, because it does not take into account what a perfectly reasonably human is likely to do erroneously. To say that it is not the fault of 'C' which leaves this pitfall (and the others we know and love), for we mortals to fall into, is like blaming the driver in an accident caused by the car's gas and brake pedals being positioned too close. Obviously the driver is not operating the controls properly, but it is the design of the controls that makes it *easy* to make the mistake. -- Ray Dunn. | UUCP: ray@philmt.philips.ca Philips Electronics Ltd. | ..!{uunet|philapd|philabs}!philmtl!ray 600 Dr Frederik Philips Blvd | TEL : (514) 744-8200 Ext : 2347 (Phonemail) St Laurent. Quebec. H4M 2S9 | FAX : (514) 744-6455 TLX : 05-824090
6sigma@polari.UUCP (Brian Matthews) (10/07/89)
In article <832@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: |In article <2432@hub.UUCP>, dougp@voodoo.ucsb.edu writes: || int a=1,b=2,*p=&a,c; || c=b/*p; || First real flaw in the C grammer [sic] I have found. | It pops up in macros from time to time. Consider: | #define xavg(m) (sum+3)/m That's why anyone who knows what they're doing will parenthesize each argument in the expansion of the macro and use liberal whitespace, thusly: #define xavg(m) (sum + 3) / (m) Then things like xavg (*p) and xavg (x + y) work as expected. -- Brian L. Matthews blm@6sigma.UUCP
cpcahil@virtech.UUCP (Conor P. Cahill) (10/07/89)
In article <1067@polari.UUCP>, 6sigma@polari.UUCP (Brian Matthews) writes: > > That's why anyone who knows what they're doing will parenthesize each > argument in the expansion of the macro and use liberal whitespace, thusly: > > #define xavg(m) (sum + 3) / (m) And they will also parenthesize the entire expression: #define xavg(m) ((sum + 3) / (m)) to ensure that there are no problems with evaluation order. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
karzes@mfci.UUCP (Tom Karzes) (10/07/89)
In article <1067@polari.UUCP> 6sigma@.UUCP (Brian Matthews) writes: >That's why anyone who knows what they're doing will parenthesize each >argument in the expansion of the macro and use liberal whitespace, thusly: > >#define xavg(m) (sum + 3) / (m) > >Then things like xavg (*p) and xavg (x + y) work as expected. It's also why people who *really* know what they're doing parenthesize both the arguments and the top level of their expression macros, thusly: #define xavg(m) ((sum + 3) / (m)) Otherwise if you write something like: a / xavg(b) your buggy macro would give you: a / (sum + 3) / (b) rather than: a / ((sum + 3) / (b)) Which, as you can see, has an entirely different meaning.
fischer@iesd.auc.dk (Lars P. Fischer) (10/08/89)
In article <832@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: > It pops up in macros from time to time. Consider: > #define xavg(m) (sum+3)/m From K&R, 2.ed, p.90: Some care also has to be taken with parentheses to make sure the order of evaluation is preserved. From Harbison & Steele, 2.ed., p. 36: As a rule, it is safest always to parenthesize each parameter appearing in the macro body. The entire body, if it is syntactically an expression, should also be parenthesized. (The whole page is used by section 3.3.6 "Precedence errors in macro expansion"). So, what do we learn. Well, the above should have been: #define xavg(m) ((sum+3) / (m)) Hopefully, we also learn that any C programmer worth his salt knows K&R by heart, and has H&S handy :-). > It's even worse if someone makes a mistake like this in a system >header file... If you don't know how to use CPP you shouldn't be allowed to write system header files. /Lars -- Copyright 1989 Lars Fischer; you can redistribute only if your recipients can. Lars Fischer, fischer@iesd.auc.dk, {...}!mcvax!iesd!fischer Department of Computer Science, University of Aalborg, DENMARK. "That makes 100 errors; please try again" --TeX
sidney@saturn.ucsc.edu (Sidney Markowitz ) (10/08/89)
We were talking about: #define xavg(m) (sum+3)/m and then using the expression: xavg(*x) Interestingly enough cc on this machine (ISI, running BSD 4.3) with default settings chokes when the macro expands into the beginning of a comment in (sum+3)/*x, but not when compiled with the -ansi switch. Doesn't pAns say that comments are converted to whitespace before macro expansion, so the /* generated by the macro should never be parsed as a comment? -- sidney markowitz <sidney@saturn.ucsc.edu)
dricejb@drilex.UUCP (Craig Jackson drilex1) (10/08/89)
In article <504@oglvee.UUCP> norm@oglvee.UUCP (Norman Joseph) writes: >From article <2432@hub.UUCP>, by dougp@voodoo.ucsb.edu: >> -Message-Text-Follows- >> main() >> { >> int a=1,b=2,*p=&a,c; >> c=b/*p; >> } >> >> First real flaw in the C grammer I have found. A friend of mine was bit by this around 1981. I was rather amused then, both by the grot it shows in C, and the two days it took him to not find it before he came to me. >I think it's just as fair to say that the fault lies not in the Grammar >but in the Programmer (with apologies to Shakespeare). Not only would >the judicious use of white space have prevented this "flaw", but it makes >good sense for readability & maintenance. The question is not one of coding style, it is one of language ambiguity vs language style. In C, it is normally acceptable to elide whitespace between tokens. Even in the case of characters which may be one token or two, such as '+', it can be handled. There is one and only one parse for a+++b. But since /* is such a powerful token (being handled in the preprocessor, etc.) C cannot resolve this otherwise normal expression. Yes, whitespace cures it. But it is a wart that it needs curing at all. >What makes people afraid to hit the space bar? Is it sloth, or ignorance? I saw nothing that indicated that the poster was afraid to hit the space bar. Just that he had not done so *in this instance*. Can you truthfully say that you have placed at least one space in each place where one was allowed in every C program you have written? I haven't; the necessity of doing so makes languages like SNOBOL4 annoying. >-- >Norm Joseph - Oglevee Computer System, Inc. > UUCP: ...!{pitt,cgh}!amanue!oglvee!norm -- Craig Jackson dricejb@drilex.dri.mgh.com {bbn,ll-xn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
flaps@dgp.toronto.edu (Alan J Rosenthal) (10/09/89)
dricejb@drilex.UUCP (Craig Jackson drilex1) writes: >In C, it is normally acceptable to elide whitespace between tokens. No, only if you don't change the tokenization. For example, if you remove the whitespace in "int i;", you will change the meaning of the statement. Similarly for "a / *b", or "a - -b". >There is one and only one parse for a+++b. Indeed, and this contradicts your previous statement. If whitespace didn't matter, this would be ambiguous between "a + ++b" and "a++ + b".
ok@cs.mu.oz.au (Richard O'Keefe) (10/09/89)
In article <2063@frog.UUCP>, john@frog.UUCP (John Woods) writes: : In article <2432@hub.UUCP>, dougp@voodoo.ucsb.edu writes: : > -Message-Text-Follows- : < main() : > { : < int a=1,b=2,*p=&a,c; : > c=b/*p; : < } : > First real flaw in the C grammer I have found. : : usespacestheymakeyourcodemuchmorereadableandhappentoavoidthisproblemasa : pleasantsideeffectparentheseswouldalsobehandysincepunctuationcanbeyourfriend I am getting just a little bit sick of these "blame the victim" responses. BCPL did not have this problem, because BCPL used //... end of line comments. PL/I did not have this problem, because although it had /*...*/ comments, the character sequence / * had no other possible significance (although when feeding PL/I card decks to DOS/360 you had to be careful not to start a comment in column 1, but that's another story). The problem _is_ due to the fact that /* is potentially significant in C. We had a similar discussion last year (or was it the year before), and a couple of people posted programs that would help you find this mistake. One scheme that works rather nicely is to write a Lex script that copies characters from stdin to stdout, inserting a <begin-bold> sequence just before /* and an <end-bold> sequence just after */, where these sequences depend on your terminal (if you have the 'more' program, another idea would be to echo each character c between and included /* and */ as _^Hc; more will then try to get underlining or some other highlighting scheme on your screen). What you then do is feed your program through this filter, and it is glaringly obvious where the comments begin and end. I have written such a program to cover a variety of languages (Lisp, Pascal, C, shell scripts, &c) and it's really handy because it often pays to skim through a program just looking at the comments anyway. Here is a totally simple-minded version of the program. It doesn't understand strings or quoted characters; that isn't hard to handle. It can't prevent /* errors, but it will help you locate them. /* seecom.c -- highlight comments in C programs Usage: seecom <foobaz.c | more (relies on more(1) to handle underlining) */ #include <stdio.h> main() { int state = 0; int c; while (c = getchar(), c != EOF) { if ((unsigned)(c-1) < ' ') { /* don't underline or highlight layout characters */ putchar(c); } else if (state) { /* we are inside a comment */ /* echo _^Hc and check for '*' '/' */ putchar('_'); putchar('\010'); putchar(c); if (c == '*') { c = getchar(); if (c == '/') { putchar('_'); putchar('\010'); putchar(c); state = 0; } else { ungetc(c, stdin); } } } else { /* we are not inside a comment */ /* check for '/' '*' */ if (c == '/') { c = getchar(); if (c == '*') { printf("_\010/_\010*"); state = 1; } else { ungetc(c, stdin); putchar('/'); } } else { putchar(c); } } } if (state) { fprintf(stderr, "Unterminated comment\n"); exit(1); } exit(0); }
scott@bbxsda.UUCP (Scott Amspoker) (10/09/89)
In article <504@oglvee.UUCP> norm@oglvee.UUCP (Norman Joseph) writes: >From article <2432@hub.UUCP>, by dougp@voodoo.ucsb.edu: >> main() >> { >> int a=1,b=2,*p=&a,c; >> c=b/*p; >> } >> >> First real flaw in the C grammer I have found. >[...] >What makes people afraid to hit the space bar? Is it sloth, or ignorance? Becausesomepeoplefeelthatitistheirrighttotypeprogramsanywaytheywantand iftheydonotwanttousespacesthentheCcompilershouldunderstandthat.Afterall iftheprogramdoesnotworkthenitmustbethefaultofpoorlanguagedesign. -- Scott Amspoker Basis International, Albuquerque, NM (505) 345-5232
dg@lakart.UUCP (David Goodenough) (10/09/89)
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) sez: > It pops up in macros from time to time. Consider: > #define xavg(m) (sum+3)/m If you don't write that as: #define xavg(m) (sum+3)/(m) you deserve what you get ....... let's see xavg(i+5); -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
jnh@ecemwl.ncsu.edu (Joseph N. Hall) (10/09/89)
In article <750@philmtl.philips.ca> ray@philmtl.philips.ca (Ray Dunn) writes: > >... >No this *is* a flaw in the C grammer, because it does not take into account >what a perfectly reasonably human is likely to do erroneously. > >To say that it is not the fault of 'C' which leaves this pitfall (and the >others we know and love), for we mortals to fall into, is like blaming the >driver in an accident caused by the car's gas and brake pedals being >positioned too close. > >Obviously the driver is not operating the controls properly, but it is the >design of the controls that makes it *easy* to make the mistake. So, what? Are you going to sue AT&T for designing a language in which it is too easy to make mistakes? Go back to ALGOL. Personally, I don't consider any little "flaw" like this that rears its head when programmers start deleting white space to be a matter of any consequence. C isn't intuitively unambiguous from a lexical standpoint (unless you consider "greedy analysis" intuitive, rather than arbitrary), but I'll be damned if I'm willing to give up those wonderful two- and three-character operators, at least not until ASCII includes more than 128 standard characters. I certainly hope "Consumer Reports" never rates programming languages ... v v sssss|| joseph hall || 4116 Brewster Drive v v s s || jnh@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606 v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist -----------|| Disclaimer: NCSU may not share my views, but is welcome to.
scott@bbxsda.UUCP (Scott Amspoker) (10/10/89)
In article <4147@ncsuvx.ncsu.edu> jnh@ecemwl.UUCP (Joseph N. Hall) writes: > >I certainly hope "Consumer Reports" never rates programming languages ... Allow me :-) IN THIS ISSUE: 8 BUTTER SUBSTITUTES 10 VCRS AN EXCITING NEW PROGRAMMING LANGUAGE SURVEY ON ORAL SEX AND AIDS TRANSMISSION ... Well, there was FORTRAN, COBOL, and PL/1. Now there is a new kid on the block, 'C'. How does 'C' measure up to it's bigger brothers? We had our staffers develop small, medium, and large scale applications using C. The staffers were pick randomly at CU headquarters. Some of them knew programming and some didn't. The applications were chosen because of their mix of calculations, file management, and user interface. The actual programs they had to write consisted of: small - compute PI to 100,000 places medium - realtime MIDI application with interrupt handling large - desktop publishing system A special development system was set up that kept track of the number of compiles, mean time between compiles, and number of compile errors. The staffers were kept in a room with precisely controlled temperature, lighting, and soft music. We were greatly disappointed in C as its disadvantages almost immeadiately surfaced. First of all, you have to declare variables before they may be used. Also, most important, C has reserved words. These are the same major flaws found in Pascal which we rated unacceptable in our March 1987 issue. Also, there were simply *too many operators* (and surprisingly, no exponentiation!) Some of our staffers thought that the heavy use of curley braces '{}' was awkward since they required the shift key. Furthermore, there is a basic attitude among our staffers that any language that provides pointer types is trying to hide *something*. It was hard to tell where C ended and subroutine libraries began. However, C isn't all bad. It's fast. Almost too fast - like a car without brakes. Part of this speed is because of the complete lack of runtime checking of anything. Some of our staffers actually liked that but our more mature staffers didn't. Also, C is normally typed in at a CRT and not punched on cards - a big plus! Finally, it is recursive. All in all, we believe C will become more of a "cult" language and never seriously accepted into the mainstream. While it is fast and small we felt that the lack of string handling, exponentiation, and other omissions are too important to overlook. (A multi-level break would have been a nice touch to eliminate goto's). We do not recommend C. DEFECTS: Our factory sample contain several defects. The most serious were: Generated bad code for returning a structure from a far procedure. #include was limited to 64 levels. Bit fields assigned from left-to-right instead of right-to-left. -- Scott Amspoker Basis International, Albuquerque, NM (505) 345-5232 unmvax.cs.unm.edu!bbx!bbxsda!scott
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/10/89)
In article <2437@hub.UUCP>, dougp@voodoo.ucsb.edu writes: | You can have a**p, a+*p, a-*p but not a/*p this is an inconsistancy | in the grammar. This wouldn't have been so bad but for a bug in | the Microsoft C compiler such that: | | // c=a/*p; | e=f*q; /*comment*/ | | causes the statment e=f*p; to be commented out. the /* in the line | commented out by // is seen as the beginning of the comment. This made | localizing the error an hour job. I'm missing something... what is the bug? /* starts a comment, */ ends it. What behavior would you have expected which is more correct. Please clarify, I realize I may be missing you point, but this looks like correct behavior to me. It conforms to 3.1.9 of the proposed std. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
brianr@phred.UUCP (Brian Reese) (10/11/89)
In article <218@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes: >Becausesomepeoplefeelthatitistheirrighttotypeprogramsanywaytheywantand >iftheydonotwanttousespacesthentheCcompilershouldunderstandthat.Afterall >iftheprogramdoesnotworkthenitmustbethefaultofpoorlanguagedesign. >-- What is, is. With more power comes more responsibility. I think it is a matter of survival of the fittest. Those of us who want to survive, will adapt to our environment. To say that it is a fault in the grammar (not grammer) or the programmer (not programmar) is just plain whimpering. Everyone has their own style, that's great. Some are more readable than others, that's an opinion. I think the important thing here is to learn to adapt to what works and stop trying to place the blame on one thing. Oh, Scott. Do you really feel that "After all if the program does not work then it must be the fault of poor language design."? Come on. What ever happened to accountability? Go ahead. Flame me. Just remember, your flames still wont solve anything. Brian -- Brian Reese uw-beaver!pilchuck!seahcx!phred!brianr Physio Control Corp., Redmond, Wa. brianr@phred.UUCP "Do not write on this line. This line has been left blank intentionally."
6sigma@polari.UUCP (Brian Matthews) (10/11/89)
In article <1243@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes: |In article <1067@polari.UUCP>, 6sigma@polari.UUCP (Brian Matthews) writes: |> That's why anyone who knows what they're doing will parenthesize each |> argument in the expansion of the macro and use liberal whitespace, thusly: |> #define xavg(m) (sum + 3) / (m) | |And they will also parenthesize the entire expression: | |#define xavg(m) ((sum + 3) / (m)) Arrgh. Absolutely. Sorry for being stupid in public...
diamond@csl.sony.co.jp (Norman Diamond) (10/11/89)
In article <4147@ncsuvx.ncsu.edu> jnh@ecemwl.UUCP (Joseph N. Hall) writes: >>I certainly hope "Consumer Reports" never rates programming languages ... Actually they might some day. But Mac and Next stuff are the first sorts of things that are capable of Consumer Reports misrating. In article <229@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes: >Allow me :-) >... >Well, there was FORTRAN, COBOL, and PL/1. Now there is a new kid on the >block, 'C'. How does 'C' measure up to it's bigger brothers? Well, C is not quite the new kid on the block. Fortran's around 33 years old or so, and Cobol is in the same vicinity. C is only 19, so it is a younger brother, but it's not a kid. (Except in some ways.) -- Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work) The above opinions are inherited by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo or Anterior, then their administrators must have approved of these opinions.
scott@bbxsda.UUCP (Scott Amspoker) (10/11/89)
In article <2795@phred.UUCP> brianr@phred.UUCP (Brian Reese) writes: >In article <218@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes: >>Becausesomepeoplefeelthatitistheirrighttotypeprogramsanywaytheywantand >>iftheydonotwanttousespacesthentheCcompilershouldunderstandthat.Afterall >>iftheprogramdoesnotworkthenitmustbethefaultofpoorlanguagedesign. >>-- > >Oh, Scott. Do you really feel that "After all if the program does not work >then it must be the fault of poor language design."? Come on. What ever >happened to accountability? Whatever happened to sarcasm? I thought my posting was obviously sarcastic. Sorry. (smileys next time) I agree totally. As a developer of a business language we get calls all of the time from people who can't seem to get their program working and, of course, it's entriely our fault! <- sarcasm. Nobody knows more than I how ridiculous that argument is. -- Scott Amspoker Basis International, Albuquerque, NM (505) 345-5232 unmvax.cs.unm.edu!bbx!bbxsda!scott
john@wsl.UUCP (John Allen on wsl) (10/12/89)
All 'C' programmers please note the following about the dreadful mistake in the definition of the 'C' grammar. The /* construct for start of comment is not in the 'C' compiler but in the preprocessor. (Simple solutuin write your own preprocessor which uses something different instead). 'C' programmers are expected to be way above the normal slogger. FACT 1: You think, the compiler compiles. FACT 2: You make mistake, the compiler compiles. FACT 3: You make mistake, if the compiler can't find it, you will have to. We all know 'C' is not perfect, what language is, and if there is a perfect language then use it and stop complaining about thing in the 'C' language that a little bit of white space gets rid off.
ok@cs.mu.oz.au (Richard O'Keefe) (10/12/89)
In article <267@wsl.UUCP>, john@wsl.UUCP (John Allen on wsl) writes: > The /* construct for start of comment is not in the 'C' compiler but in the > preprocessor. Historically this is not true. The PDP-11 C compilers didn't even *run* the preprocessor unless the very first character of the file was a '#'. I have seen the sources of the UNIX V7 C compiler for PDP-11s, and I can assure you that the tokeniser did most definitely handle comments. To this day, /lib/cpp (if you have it) usually includes an option -C, which causes comments in the input to be preserved in the output, and many UNIX C compilers will accept foobaz.c - DO use the preprocessor foobaz.i - DON'T use the preprocessor I just double-checked this on a Sun-3/50 running SunOS 4.0_Export, and when that C compiler is given a *.i file it _does_ accept comments but it _doesn't_ accept #define, so PCC at least still handles comments in the compiler. It wasn't true in the Snyder compiler for DEC-10s either, where the preprocessor was part of the compiler, not a separate program.
karzes@mfci.UUCP (Tom Karzes) (10/12/89)
In article <267@wsl.UUCP> john@wsl.UUCP (John Allen on wsl) writes: >The /* construct for start of comment is not in the 'C' compiler but in the >preprocessor. I don't believe that's part of the language definition. Traditionally, however, comment recognition exists in BOTH the C preprocessor and the compiler. On most Unix systems with pcc-derived compilers, cpp will, by default, strip comments, but has a -C switch which will cause it to pass them through, in which case the compiler will ignore them. By taking advantage of the fact that cpp won't back up past the point of a macro expansion, and the fact that the beginning of a comment is indicated by a pair of characters, it is possible to sneak comments through cpp even with the default behavior of stripping comments. For example: % cat cic.c /* This is a comment which cpp will catch */ #define X()* /X() This is a comment which will sneak by cpp */ main() { printf("No syntax error.\n"); } % If this is run through cpp, the first comment is stripped and the second is "introduced": % /lib/cpp cic.c # 1 "cic.c" /* This is a comment which will sneak by cpp */ main() { printf("No syntax error.\n"); } % As you can see, the compiler will ignore this comment: % cc cic.c -o cic % cic No syntax error. % Finally, if the -C switch is passed to cpp, both comments are retained: % /lib/cpp -C cic.c # 1 "cic.c" /* This is a comment which cpp will catch */ /* This is a comment which will sneak by cpp */ main() { printf("No syntax error.\n"); } %
utoddl@uncecs.edu (Todd M. Lewis) (10/12/89)
[lots of ragging some guy for pointing out a weakness in
C's grammar deleted]
Jeepers, folks, lighten up. The poor guy just said that C
has some sharp corners and pointed one out. One of my favorite
is this:
if (a=b) { ...
I used to spend about an hour per program tracking down this
little beauty. But that's not the point.
The point is that certain pitfalls are inherent in the
language grammer. Be aware of them. And, no, it isn't good
enough to say, "Sure it has sharp edges, you just have to
be careful how you use it." If C were a kitchen appliance
it would be taken off the market due to excessive domestic
carnage. If you can avoid putting similar pitfalls in your
own products, so much the better. (I especially liked the
attitude of the guy how thought his customers idiots because
they found his product difficult to use:-)
_____
| Todd M. Lewis Disclaimer: If you want my employer's
||\/| utoddl@ecsvax.uncecs.edu ideas, you'll have to
|| || utoddl@ecsvax.bitnet _buy_ them.
| ||
|___ ("Prgrms wtht cmmnts r lk sntncs wtht vwls." --TML)scott@bbxsda.UUCP (Scott Amspoker) (10/12/89)
In article <267@wsl.UUCP> john@wsl.UUCP (John Allen on wsl) writes: >We all know 'C' is not perfect, what language is, and if there is a perfect >language then use it and stop complaining about thing in the 'C' language >that a little bit of white space gets rid off. Another easy pitfall in C is forgetting to close a comment. On compilers that don't nest comments this will cause some code to be swallowed up until the next comment. You can stare at it for the longest time and not see the problem. I wrote a quick and dirty program one day to scan C programs looking for "nested" comments and reporting on them. It take but a few seconds to scan a whole directory of C source files. I highly recommend keeping such a program handy. -- Scott Amspoker Basis International, Albuquerque, NM (505) 345-5232 unmvax.cs.unm.edu!bbx!bbxsda!scott
karzes@mfci.UUCP (Tom Karzes) (10/13/89)
In article <1989Oct12.122841.22514@uncecs.edu> utoddl@uncecs.edu (Todd M. Lewis) writes:
- The point is that certain pitfalls are inherent in the
-language grammer. Be aware of them.
If you'd been following this discussion closely enough to warrant your
critical response, you'd know how to spell grammar.davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/14/89)
In article <9999@cbnews.ATT.COM>, smk@cbnews.ATT.COM (Stephen M. Kennedy) writes: | Why did you put this in the pointers section? This is just a poorly | parenthesized macro. Consider "y = 1 / xavag(10);" or "xavg(n * 10)". Oops! I meant pointers as in "helpful hints", not the "pointer to TYPE" sense. This is a section on common errors, and a few not so common but really hard to find. When trying to tell students to use loads of parens in macros defs I liked the example as a case of something which appears to work but fails because the parens are missing. Based on feedback from students, a "horrible example" of what can happen if done wrong helps make the warning stick. My use of 'Pointers" was certainly not clear in context. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
brianr@phred.UUCP (Brian Reese) (10/14/89)
In article <239@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes: >In article <2795@phred.UUCP> brianr@phred.UUCP (Brian Reese) writes: >>Oh, Scott. Do you really feel that "After all if the program does not work >>then it must be the fault of poor language design."? Come on. What ever >>happened to accountability? > >Whatever happened to sarcasm? I thought my posting was obviously sarcastic. >Sorry. (smileys next time) > Uh...hi Scott...sorry. Please accept my apology. With all the discussion on this topic, it was kinda hard to tell who was serious and who wasn't. I'll try to be more intuitive next time. (How do you make a smiley with a red face?) Brian -- Brian Reese uw-beaver!pilchuck!seahcx!phred!brianr Physio Control Corp., Redmond, Wa. brianr@phred.UUCP "Sticks and stones may break my bones, but whips and chains excite me!" * Do not write on this line. This line has been left blank intentionally. *
keesan@bbn.com (Morris M. Keesan) (10/14/89)
In article <9999@cbnews.ATT.COM> smk@cbnews.ATT.COM (Stephen M. Kennedy writes > p.s. In another article, did someone say it was ok to define an abs macro as > -(x)? What about "y = -abs(x);"? But -(x) is not the entire body of the macro. The macro was #define ABS(x) ((x) < 0 ? -(x) : (x)) and in this context, -(x) is fine and doesn't need to be (-(x)), because the whole macro has an outer set of parentheses. ------------------------------------------------------------------------------ Morris M. Keesan | Internet: keesan@bbn.com | UUCP: Figure it out from the path |
lmb@ghoti.uucp (Larry Breed) (10/14/89)
In article <1989Oct12.122841.22514@uncecs.edu> utoddl@uncecs.edu (Todd M. Lewis) writes: >One of my favorites >is this: > if (a=b) { ... >I used to spend about an hour per program tracking down this >little beauty. Around here we use the terms "the test for present equality" (a==b) and "the test for future equality" (a=b). -- If they weren't before, they are now... Disclaimer: Don't blame my employer, blame: Larry Breed (415) 855-4460 uucp: uunet!ibmsupt!lmb inet: ibmsupt!lmb@uunet.uu.net
goudreau@dg-rtp.dg.com (Bob Goudreau) (10/17/89)
In article <244@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes: > >Another easy pitfall in C is forgetting to close a comment. On compilers >that don't nest comments this will cause some code to be swallowed up Any compiler that allows nesting of comments isn't a C compiler anyway, by either K&R or ANSI standards. ------------------------------- Bob Goudreau +1 919 248 6231 Data General Corporation ...!mcnc!rti!xyzzy!goudreau 62 Alexander Drive goudreau@dg-rtp.dg.com Research Triangle Park, NC 27709, USA
ds@hollin.prime.com (10/17/89)
I could never get used to the difference between = and ==, so I use "#define EQ ==" (and "#define NE !=" for symmetry) as part of my standard defines at the start of every program. While the lexical distinction remains, it is now reflected more thoroughly by the difference between punctuation and alphabetical characters. David Spector Prime Computer, Inc. ds@primerd.prime.com (until the layoff)
6600pete@ucsbuxa.ucsb.edu (10/17/89)
In article <192700007@hollin> ds@hollin.prime.com writes:
I could never get used to the difference between = and ==, so I use
"#define EQ ==" (and "#define NE !=" for symmetry) as part of my
standard defines at the start of every program. While the lexical
distinction remains, it is now reflected more thoroughly by the
difference between punctuation and alphabetical characters.
Another good way to do this, at least when comparing to a constant, is
to put the constant first in an expression, like so
if ( 1 == x ) {
No C compiler will accept
if ( 1 = x ) {scott@bbxsda.UUCP (Scott Amspoker) (10/17/89)
In article <1901@xyzzy.UUCP> goudreau@rtp48.dg.com (Bob Goudreau) writes: >In article <244@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes: >> >>Another easy pitfall in C is forgetting to close a comment. On compilers >>that don't nest comments this will cause some code to be swallowed up > >Any compiler that allows nesting of comments isn't a C compiler anyway, >by either K&R or ANSI standards. Believe it or not - that is a command line switch on some C compilers. -- Scott Amspoker Basis International, Albuquerque, NM (505) 345-5232 unmvax.cs.unm.edu!bbx!bbxsda!scott
goudreau@dg-rtp.dg.com (Bob Goudreau) (10/19/89)
In article <255@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes: >In article <1901@xyzzy.UUCP> goudreau@rtp48.dg.com (Bob Goudreau) writes: > >In article <244@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes: > >> > >>Another easy pitfall in C is forgetting to close a comment. On compilers > >>that don't nest comments this will cause some code to be swallowed up > > > >Any compiler that allows nesting of comments isn't a C compiler anyway, > >by either K&R or ANSI standards. > >Believe it or not - that is a command line switch on some C compilers. My point was that any such compilers (or compiler-instantiations created by invoking the same program with different switches) may *claim* to be C compilers, but claiming isn't enough. Such compilers are *broken*, at least as C compilers. Now if they advertised themselves as compilers for a language that's sort of like (but not really) C, then that's another story. But if they're going to monkey with fundamental parts of the language definition (and yes, the language definition includes preprocessor directives) in their compiler, who's to say what else they'll break? ----------------------------------------- Bob Goudreau +1 919 248 6231 Data General Corporation ...!mcnc!rti!xyzzy!goudreau 62 Alexander Drive goudreau@dg-rtp.dg.com Research Triangle Park, NC 27709, USA
scott@bbxsda.UUCP (Scott Amspoker) (10/19/89)
Scott Amspoker writes: >>>>Another easy pitfall in C is forgetting to close a comment. On compilers >>>>that don't nest comments this will cause some code to be swallowed up I was incorrect in my above comment. Nested comments have *nothing* to do with it. Bob Goudreau writes: >>>Any compiler that allows nesting of comments isn't a C compiler anyway, >>>by either K&R or ANSI standards. Scott Amspoker writes (FYI): >>Believe it or not - that is a command line switch on some C compilers. Bob Goudreau writes: >My point was that any such compilers (or compiler-instantiations created >by invoking the same program with different switches) may *claim* to be >C compilers, but claiming isn't enough. Such compilers are *broken*, at >least as C compilers. >[...] I don't get it. Are you saying that a C compiler that allows the option of nested comments is *broken*? I believe Turbo C has a nested comments option. I agree that a compiler that insists on nesting comments is probably non-conforming (I say "probably" because I can't recite the actual ANSI text at this moment). But what's wrong with command line options that allow various enhancements? -- Scott Amspoker Basis International, Albuquerque, NM (505) 345-5232 unmvax.cs.unm.edu!bbx!bbxsda!scott
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/20/89)
In article <273@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes: >I don't get it. Are you saying that a C compiler that allows the option >of nested comments is *broken*? I believe Turbo C has a nested comments >option. I agree that a compiler that insists on nesting comments is >probably non-conforming (I say "probably" because I can't recite the >actual ANSI text at this moment). But what's wrong with command line >options that allow various enhancements? C does not now, and never has, permitted nested /*...*/ comments. A compiler when it does treat /*...*/ comments as nesting (however the compiler is invoked) is not processing the C programming language. If it is advertised as a C compiler in that mode, then yes it is broken. What is wrong with this "enhancement" is that it is not a transparent extension. It encourages writing code that looks like C but performs differently from the way C code would. When ported to a genuine C environment, its operation can change, perhaps silently getting wrong answers when compiled by a true C compiler. Vendor extensions to C should be clearly identifiable, so that it is easy to determine if an application is relying on them, and they should be designed to cause diagnostics when code using them is compiled in an environment that does not support the extensions.
scott@bbxsda.UUCP (Scott Amspoker) (10/21/89)
In article <11348@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <273@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes: >>I don't get it. Are you saying that a C compiler that allows the option >>of nested comments is *broken*? I believe Turbo C has a nested comments >>option. >>[...] >[...] >What is wrong with this "enhancement" is that it is not a transparent >extension. It encourages writing code that looks like C but performs >differently from the way C code would. I'm still confused. The compilers I've seen doing this have a compiler switch that must be deliberately set by the programmer who has made a concious decision to use nested comments. You seem to think that, even though it doesn't affect you at all, others still should not be allowed to do it because it's not good for them. Whatever you say. I am discontinuing participation in this thread. Frankly, I think it should be moved to soc.religion. -- Scott Amspoker Basis International, Albuquerque, NM (505) 345-5232 unmvax.cs.unm.edu!bbx!bbxsda!scott
cpcahil@virtech.UUCP (Conor P. Cahill) (10/21/89)
In article <11348@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > C does not now, and never has, permitted nested /*...*/ comments. > A compiler when it does treat /*...*/ comments as nesting (however > the compiler is invoked) is not processing the C programming language. > If it is advertised as a C compiler in that mode, then yes it is broken. I agree 100% with this, but it sure would be nice to have a compile time flag that would turn on warnings about nested/unmatched comment areas. This would make it easier to find the old problem of: some c code /* this is a comment for that code *? some code that now won't be executed... /* real end of the comment */ I am not asking for nested comments, but for a warning if they do occur (and the appropriate flag has been passed to the compiler). -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
bobmon@iuvax.cs.indiana.edu (RAMontante) (10/22/89)
cpcahil@virtech.UUCP (Conor P. Cahill) <1297@virtech.UUCP> : - -I agree 100% with this, but it sure would be nice to have a -compile time flag that would turn on warnings about nested/unmatched -comment areas. This would make it easier to find the old problem - [ ... ] -I am not asking for nested comments, but for a warning if they do -occur (and the appropriate flag has been passed to the compiler). Heyyyy! You want... Turbo C ! ! ! ! All the world is *not* a VAX --- all the world is a PC/XT (MOOO-hahahahahaha...)
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/22/89)
In article <280@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes: >In article <11348@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >>What is wrong with this [nested comment] "enhancement" is that it is not a >>transparent extension. It encourages writing code that looks like C but >>performs differently from the way C code would. >You seem to think that, even though it doesn't affect you at all, others >still should not be allowed to do it because it's not good for them. No, to take an analogy: I wouldn't want to encourage smoking, because it's not healthy, even though so long as it's done in private I wouldn't outlaw it either. Supporting nested comments in C constitutes active encouragement of an unhealthy practice, and I recommend against compiler vendors doing it.
dougp@voodoo.ucsb.edu (10/22/89)
-Message-Text-Follows- In article <11368@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes... >No, to take an analogy: I wouldn't want to encourage smoking, because it's >not healthy, even though so long as it's done in private I wouldn't outlaw >it either. Supporting nested comments in C constitutes active encouragement >of an unhealthy practice, and I recommend against compiler vendors doing it. So you recomend that compiler vendors make no inovations? You would not now have function prototypes or the void type, two of the nicest aditions to the C language if it wern't for nonstandard enhancements to C compilers. If I remember correctly these were not in the K&R definition of the C language, but they appeared in many C compilers before the ANSI commitie blessed the practice. I am all for nonstandard enhancements That is how new features get added to the language. They first appear in a nonstandard C, if they are no good, nobody uses them, if they are good people will start complaining if they arn't in the compiler they are using untill it gets added. Thus good features proliferate and bad ones die. It's called evolution. Besides, quite a bit of code is written that is and must be hardware specific (can you say int far *?) infact most applications on PC's are written in a machine specific manor. (Have you looked at Macintosh, Windows, Atari ST/GEM, or Amiga/Intuition code?) As for nonstandard features, here are two I'd like to see for the preprocessor: A #define that would replace text even within tokens so I could do something like #define @ * and @ptr would be translated to *ptr. This would also be nice for those who are foreced to use triglifs, they could substatute a charactor in their own charactor set for a triglif and not have it die when they are tring to do something like {a=x} (Whitespace lovers please don't waste a lot of bandwidth on this, sometimes it is clearer without whitespace) I'd also like to see /# comment #/ as the nested comment charactor (can anyone think of a way /# or #/ would look like some other operation like /* can?) maby /* */ can be sent the way of =* Douglas Peale
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/22/89)
In article <2651@hub.UUCP> dougp@voodoo.ucsb.edu writes:
-In article <11368@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes...
->No, to take an analogy: I wouldn't want to encourage smoking, because it's
->not healthy, even though so long as it's done in private I wouldn't outlaw
->it either. Supporting nested comments in C constitutes active encouragement
->of an unhealthy practice, and I recommend against compiler vendors doing it.
-So you recomend that compiler vendors make no inovations?
Don't put words into my mouth. I explained previously why the SPECIFIC
"innovation" of nested comments was unhealthy.hascall@atanasoff.cs.iastate.edu (John Hascall) (10/23/89)
In article <2651@hub.UUCP> dougp@voodoo.ucsb.edu writes: }#define @ * }and @ptr would be translated to *ptr. This would also be nice for }I'd also like to see /# comment #/ as the nested comment charactor }(can anyone think of a way /# or #/ would look like some other }operation like /* can?) maby /* */ can be sent the way of =* If only K&R had choosen not to overload "*" and used "@" for pointer dereferencing (i.e., @ptr). It even reads right: "at ptr"! Poor old "@" is just about the only character on the keyboard ignored by C!! (` is the other) I have wondered about this for some time, can anyone shed some light on this? I think nested comments are more dangerous than useful. When I still did some work in Pascal, I wished for them so I could comment out a block of code without having to manually mung all of the comments, but with C you've got "#ifdef" to work with. John Hascall
joe@modcomp.UUCP (10/23/89)
>>Supporting nested comments in C constitutes active encouragement of an >>unhealthy practice, and I recommend against compiler vendors doing it. >So you recomend that compiler vendors make no inovations? You would not Now, now, not supporting nested comments is *not* the same as not supporting innovation. For one thing, the change is not upwards compatible with the standard -- which, in my opinion, kills the idea right there. -- joe korty "for every vengence there is an equal and uunet!modcomp!joe opposite revengence." (from Cartoon Laws)
henry@utzoo.uucp (Henry Spencer) (10/23/89)
In article <2651@hub.UUCP> dougp@voodoo.ucsb.edu writes: >>... Supporting nested comments in C constitutes active encouragement >>of an unhealthy practice, and I recommend against compiler vendors doing it. > >So you recomend that compiler vendors make no inovations? ... I'm fairly sure that Doug agrees with me on this one: it's highly desirable for compiler vendors to make *useful* innovations, but nested comments aren't. They're an attempt to fix something that basically isn't broken. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (10/23/89)
In article <1651@atanasoff.cs.iastate.edu> hascall@atanasoff.UUCP (John Hascall) writes: > Poor old "@" is just about the only character on the keyboard ignored > by C!! (` is the other) Historically, `#' and `@' were avoided in the original C because they were the normal Unix `erase' and `kill' characters of the time. (This convention was inherited from Multics, which did things that way because of the need to support terminals with no unprintable characters, e.g. 2741s.) The C preprocessor, added later, used `#' as the least-painful escape out of C. (I tentatively assume that yacc was already using `$', which otherwise might have been a good choice -- I'm not sure about the relative timing of cpp and yacc). ``' did get used a little bit in obscure early implementations of C, and in fact some compilers will still give you odd-sounding error messages if one creeps into your source. Nobody has ever quite gotten around to using `@' in C. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
goudreau@dg-rtp.dg.com (Bob Goudreau) (10/24/89)
In article <273@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes: >Bob Goudreau writes: > >>My point was that any such compilers (or compiler-instantiations created >>by invoking the same program with different switches) may *claim* to be >>C compilers, but claiming isn't enough. Such compilers are *broken*, at >>least as C compilers. > >I don't get it. Are you saying that a C compiler that allows the option >of nested comments is *broken*? I believe Turbo C has a nested comments >option. Yes, please re-read my reply. Any such language translator is *broken* if it purports to be a translator of the C language, for the simple reason that such a program violates translator behavior that is mandated by all the important definitions of the C language (K&R, ANSI). I'm not saying that this fact necessarily means such programs are useless and should be discarded immediately; I'm just saying that it is wrong to say that they are C compilers. Also note that I spoke of "compiler-instantiations created by invoking the same program with different switches". By that I mean that each invocation of a compiler is, in effect, a completely different program if the command line switches cause different behavior. So, while "turbocc -nest-comments" (or whatever) may indeed fail as a C compiler, "turbocc" without that switch may be valid. >I agree that a compiler that insists on nesting comments is >probably non-conforming (I say "probably" because I can't recite the >actual ANSI text at this moment). Replace the "probably" with a "definitely" (see section 3.1.9 of the pANS). And note that this is not an ANSI invention; comments have never nested in the C language. More to the point, the pre-ANSI de facto standard (K&R) did not even allow implementations the latitude to *choose* their behavior in this regard. K&R 1 states unambiguously at the beginning of Appendix A: "Comments do not nest." >But what's wrong with command line options that allow various >enhancements? Nothing, in general. But I have three particular bones to pick with respect to this "enhancement": 1) It is not upward compatible with C. It is possible to take valid, portable C source code and compile it in this manner and get a program that runs differently than expected. 2) It encourages use of this non-feature by programmers who might think that they are writing portable C code. I know, they should know better, but why add this pitfall at all? 3) It is not even necessary. How is it any better than using "#if 0 .... #endif" as a mechanism for "commenting-out" code blocks? ------------------------- Bob Goudreau +1 919 248 6231 Data General Corporation ...!mcnc!rti!xyzzy!goudreau 62 Alexander Drive goudreau@dg-rtp.dg.com Research Triangle Park, NC 27709, USA
austin@bucsf.bu.edu (Austin Ziegler) (10/24/89)
>>>>> On 23 Oct 89 20:59:25 GMT, goudreau@dg-rtp.dg.com (Bob Goudreau) said: Bob> In article <273@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes: >Bob Goudreau writes: > >> Such compilers are *broken*, at least as C compilers. > >I don't get it. Are you saying that a C compiler that allows the option >of nested comments is *broken*? I believe Turbo C has a nested comments >option. Bob> Yes, please re-read my reply. Any such language translator is *broken* Bob> if it purports to be a translator of the C language, for the simple Bob> reason that such a program violates translator behavior that is mandated Bob> by all the important definitions of the C language (K&R, ANSI). I read the rest of your article, but this is the one part I have problems with. I am originally a Pascal programmer, and have been programming in C for enough time to acquaint myself with the language. In Pascal, one of the nicest features for debugging is nested comments. This is provided as a *Debugging* feature *only* in Turbo C. Nowhere does Borland state that you should use that feature in normal programming. As a rule, I do not use nested comments in C, but I *have* found the need to comment it out because I am not fully acquainted with all of the features of the preprocessor commands. I do not think that a compiler which supports Nested Comments (in either command-line or integrated debugging modes) is *broken* at all. Much of Borland's C market exists from their Pascal programmers, and yes, it is hard to break old habits (be they good or bad). I think that this is a valid *option* but I agree with you, Bob, that it should not be the Standard. Elminster, the Sage of Shadowdale (austin@bucsf.bu.edu) 700 Commonwealth Box 2094, Boston, MA 02215 I am *NOT* a C guru, I just try to be. I *AM* a Pascal guru, when I want to be.
ok@cs.mu.oz.au (Richard O'Keefe) (10/24/89)
In article <41019@bu-cs.BU.EDU>, austin@bucsf.bu.edu (Austin Ziegler) writes: > I read the rest of your article, but this is the one part I have > problems with. I am originally a Pascal programmer, and have been > programming in C for enough time to acquaint myself with the language. In > Pascal, one of the nicest features for debugging is nested comments. Er, there's something your best friend should have told you: Pascal comments DO NOT NEST. Neither in the ANSI standard, nor the ISO standard, nor Jensen & Wirth, nor either of the Pascal compilers I just checked (although one of them prints a warning if it sees '(*' inside '(*'). Here is a Pascal program. | program nestcom(input, output); | begin | (* comments in Pascal do not nest: | (* this is not a nested comment *) | writeln('This is not commented out'); | (* this is not a nested comment *) | writeln('This *) does not close any comment'); | end (* nestcom *). Compiling and running this program produces the output | This is not commented out | This *) does not close any comment A Pascal processor which conforms to the standard may still have trouble with it (the output lines might be too long or it might not support lower case or something), but modulo case this is the only valid output from it. Any Pascal processor which treats these comments as nested VIOLATES THE STANDARD. > I *have* found the need to > comment it out because I am not fully acquainted with all of the features > of the preprocessor commands. The only preprocessor directives you need to know are #if 0 <this will be tokenised but not otherwise processed> #endif It is extremely important to realise that nested comments are "pushed" as a debugging tool, BUT THEY DO NOT WORK RELIABLY FOR THAT PURPOSE. If the code you are commenting out contains comment delimiters, putting nested comment delimiters around it is going to land you in big trouble. A UNIX C programmer might be likely to call f = popen("ls SCCS/*.p", "r"); ^^ If you have an Emacs-like editor, it is extremely easy to write a comment-out-region command which works just fine without needing nested comments. Mine turns /<N spaces>* into /<N+1 spaces>* and similarly for *<N spaces>/, comment-in-region decrements the number of spaces and removes the outer delimiter pair. > I *AM* a Pascal guru, when I want to be. Pascal gurus have memorized the Standard.
chip@ateng.com (Chip Salzenberg) (10/24/89)
According to austin@bucsf.bu.edu (Austin Ziegler): >In Pascal, one of the nicest features for debugging is nested comments. Of course, let us not forget that Pascal has two kinds of comment delimiters, (* *) and { }, and that nesting { { } } or (* (* *) *) doesn't work. C has only /* */. >This is provided as a *Debugging* feature *only* in Turbo C. Nowhere does >Borland state that you should use that feature in normal programming. Nested comments are a _bug_, not a feature, Borland apologists notwithstanding. >I *have* found the need to comment it out because I am not fully >acquainted with all of the features of the preprocessor commands. Ignorance of the language is no excuse. All that's needed is: #if 0 /* never do this */ system("delete *.*"); #endif -- You may redistribute this article only to those who may freely do likewise. Chip Salzenberg at A T Engineering; <chip@ateng.com> or <uunet!ateng!chip> "'Why do we post to Usenet?' Naturally, the answer is, 'To get a response.'" -- Brad "Flame Me" Templeton
austin@bucsf.bu.edu (Austin Ziegler) (10/24/89)
>>>>> On 24 Oct 89 09:20:32 GMT, ok@cs.mu.oz.au (Richard O'Keefe) said: RO> In article <41019@bu-cs.BU.EDU>, austin@bucsf.bu.edu (Austin Ziegler) writes: > I read the rest of your article, but this is the one part I have > problems with. I am originally a Pascal programmer, and have been > programming in C for enough time to acquaint myself with the language. In > Pascal, one of the nicest features for debugging is nested comments. RO> Er, there's something your best friend should have told you: Pascal RO> comments DO NOT NEST. Neither in the ANSI standard, nor the ISO RO> standard, nor Jensen & Wirth, nor either of the Pascal compilers I just RO> checked (although one of them prints a warning if it sees '(*' inside RO> '(*'). Every pascal compiler I have seen accepts both '{' and '(*' as characters which start comments. That means you could have a { (* *) } comment or a (* { } *) comment. Beyond that, Pascal DOES NOT NEST. Even though they are two different sets of characters, they both delimit comments. Another point in case for multiple forms is '[]' and '(..)'. Followups directed to comp.lang.pascal before this gets too far out of the range of C. Elminster, the Sage of Shadowdale (austin@bucsf.bu.edu) 700 Commonwealth Box 2094, Boston, MA 02215 (* This is a { nested } comment in Pascal. *)
jharkins@sagpd1.UUCP (Jim Harkins) (10/24/89)
In article <1989Oct23.161744.29153@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Nobody has ever quite gotten around to using `@' in C. I know, we'll use @ for nested comments! :-) jim "Any day now we're gonna have the big one and everything east of the San Andreas fault will slide into the Atlantic."
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/25/89)
In article <2651@hub.UUCP>, dougp@voodoo.ucsb.edu writes: | A #define that would replace text even within tokens so I could | do something like | | #define @ * Yecch! As my youngest used to say "yucckie-poo!". I can see the side effects of in-token substitution: #define put get The parser would be a bear, since every part of every token would have to be checked. The only use for this I can see is to compete in the obfuscated C contest. You can do operator overloading in a number of languages. | I'd also like to see /# comment #/ as the nested comment charactor | (can anyone think of a way /# or #/ would look like some other | operation like /* can?) maby /* */ can be sent the way of =* There is already a way to comment out code which doesn't depend on any nested whatever: #if 0 ... #endif does nicely, and IT can be nested. I think adding /# is unnecessary and replacing it would break too many programs. I do agree that /* was not the best idea for a comment delimiter, but hindsight is wonderful. I think a previously unused symbol like $ as a comment inducer would be nice, but that's an American symbol and would have to be replaced by a triglyph. I certainly wouldn't suggest a change now because the problems are slight and well known. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
djones@megatest.UUCP (Dave Jones) (10/25/89)
From article <41063@bu-cs.BU.EDU>, by austin@bucsf.bu.edu (Austin Ziegler): > > Every pascal compiler I have seen accepts both '{' and '(*' as > characters which start comments. That means you could have a { (* *) } > comment or a (* { } *) comment. BRZZZZT. I'm sorry, Mr. Ziegler, but we have some lovely consolation prizes waiting for you back stage. In every Pascal I am familiar with, the following is a complete comment: { (* *) The type of comment delimiters does not have to match. _Standard_Pascal_ by Cooper mentions this explictly on page 7, and sez, paraphrasing now, "Don't DO that, squid-brain."
karl@haddock.ima.isc.com (Karl Heuer) (10/25/89)
In article <509@sagpd1.UUCP> jharkins@sagpd1.UUCP (Jim Harkins) writes: >In article <1989Oct23.161744.29153@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>Nobody has ever quite gotten around to using `@' in C. > >I know, we'll use @ for nested comments! :-) It's been done. (The timestamp on the hardcopy is 02:09 03-Apr-1980, but I think I must have written it a couple of years before that.) Actually, I used /@...@/ for the nestable comment, and implemented a few other "improvements" that couldn't be done with simple preprocessor abuse. But I was a C novice back then, and hadn't noticed that #if...#endif does the job better. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint (The other advantage of that notation is that it gave me an excuse to use the graphic __@/ , which should be familiar to anyone who consulted OLIVER the Bookie or was a member of the Caltech Odd Hack Committee.)
diamond@csl.sony.co.jp (Norman Diamond) (10/25/89)
In article <41019@bu-cs.BU.EDU> austin@bucsf.bu.edu (Austin Ziegler) writes: >In Pascal, one of the nicest features for debugging is nested comments. Sounds like your Pascal compiler is just as badly broken as your C compiler. Any pseudo-compiler that reads pseudo-Pascal source but likes nested comments is not a Pascal compiler, just as with C. Take your choice; read the old Pascal standard or the new Extended Pascal standard. Comments do not nest. -- Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work) Should the preceding opinions be caught or | James Bond asked his killed, the sender will disavow all knowledge | ATT rep for a source of their activities or whereabouts. | licence to "kill".
exspes@gdr.bath.ac.uk (P E Smee) (10/25/89)
In article <1989Oct23.160518.28851@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >I'm fairly sure that Doug agrees with me on this one: it's highly desirable >for compiler vendors to make *useful* innovations, but nested comments aren't. >They're an attempt to fix something that basically isn't broken. But they *can* be useful, particularly in the development stages of a program. If contents nest, then you can comment out blocks of your code for various trial purposes, without having to worry about what's in the block you comment out. I've known PL/1 programmers to avoid commenting their code because (since PL/1 comments don't nest) it would inhibit this handy testing trick. I *will* grant that I feel strongly that nested comments should *not* be the default, but should require that the capability be turned on using a compiler control argument; and that any sane company would establish as policy that this option *could not* be used in compiling production or release versions of the code. -- Paul Smee | JANET: Smee@uk.ac.bristol Computer Centre | BITNET: Smee%uk.ac.bristol@ukacrl.bitnet University of Bristol | Internet: Smee%uk.ac.bristol@nsfnet-relay.ac.uk (Phone: +44 272 303132) | UUCP: ...!mcvax!ukc!gdr.bath.ac.uk!exspes
diamond@csl.sony.co.jp (Norman Diamond) (10/25/89)
In article <41063@bu-cs.BU.EDU> austin@bucsf.bu.edu (Austin Ziegler) writes: > Every pascal compiler I have seen accepts both '{' and '(*' as >characters which start comments. Yes. The standard requires it too. >That means you could have a { (* *) } >comment or a (* { } *) comment. No. { (* *) } start part of comment end of comment syntax error (* { } *) start part of comment end of comment syntax error >Beyond that, and including that, >Pascal DOES NOT NEST. Even >though they are two different sets of characters, they both delimit >comments. Exactly. -- Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work) Should the preceding opinions be caught or | James Bond asked his killed, the sender will disavow all knowledge | ATT rep for a source of their activities or whereabouts. | licence to "kill".
mustard@sdrc.UUCP (Sandy Mustard) (10/25/89)
In article <1989Oct23.161744.29153@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > Nobody has ever quite gotten around to using `@' in C. Actually somebody has!! SAS C on 370 has an option to allow the '@' character to indicate that the argument in a function call should be passed by reference. It basically has the same meaning as the '&' but the '@' can be used on non-lvalues such as constants and expressions. char c; func(&c, @20); will cause a pointer to a temporary copy of an int with a value of 20 to be passed to the function. Sandy Mustard
ok@cs.mu.oz.au (Richard O'Keefe) (10/26/89)
In article <1989Oct25.090616.19276@gdt.bath.ac.uk>, exspes@gdr.bath.ac.uk (P E Smee) writes: > If contents nest, then you can comment out blocks of your code > for various trial purposes, without having to worry about what's in the > block you comment out. This claim is false, as I pointed out before. If you comment out code containing strings containing comment delimiters, you're in trouble. (Yes, this bit me several times.) > I've known PL/1 programmers to avoid commenting > their code because (since PL/1 comments don't nest) it would inhibit this > handy testing trick. In that case you have known some PL/I (that's a Roman I not an Arabic 1) programmers who either were not masters of their language or who were using an incomplete implementation. PL/I has preprocessor facilities. To omit a block of code in PL/I, just put %IF '0'B THEN %DO; <omitted stuff here> %END; around it. One more time: if you have a decent editor, and you have either PL/I-style /* */ or Pascal-style (* *) comments (but not { } comments), you can comment out regions and bring them back again WITHOUT needing nested comments as such. If anyone's interested, I'll post my code for it.
dougp@voodoo.ucsb.edu (10/27/89)
-Message-Text-Follows- In article <509@sagpd1.UUCP>, jharkins@sagpd1.UUCP (Jim Harkins) writes... >In article <1989Oct23.161744.29153@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>Nobody has ever quite gotten around to using `@' in C. > >I know, we'll use @ for nested comments! :-) > >jim >"Any day now we're gonna have the big one and everything east of the San >Andreas fault will slide into the Atlantic." I have changed my mind on wanting nested comments, someone gave a good reason why not to use them: /*printf("the comment delimiter in C is /* \n"); */ would generate an error. The best solution would be to have /* /* */ generate a warning. Douglas Peale
tneff@bfmny0.UU.NET (Tom Neff) (10/27/89)
>would generate an error. The best solution would be to have /* /* */ >generate a warning. Again -- this is a common usage in config.h type files. /* #define BSD4_3 /* for BSD 4.3 systems */ #define USG /* for System V */ /* #define V7 /* for old fogey systems */ /* #define DOS /* for young whippersnapper systems */ Nested comments are another solution in search of a problem. -- "The country couldn't run without Prohibition. ][ Tom Neff That is the industrial fact." -- Henry Ford, 1929 ][ tneff@bfmny0.UU.NET
bright@Data-IO.COM (Walter Bright) (10/28/89)
In article <1989Oct25.090616.19276@gdt.bath.ac.uk> exspes@gdr.bath.ac.uk (P E Smee) writes:
<If contents nest, then you can comment out blocks of your code
<for various trial purposes, without having to worry about what's in the
<block you comment out.
#if 0
#endif
pairs work quite nicely and portably.bright@Data-IO.COM (Walter Bright) (10/28/89)
In article <928@sdrc.UUCP> mustard@sdrc.UUCP (Sandy Mustard) writes:
<SAS C on 370 has an option to allow the '@'
<character to indicate that the argument in a function call should be
<passed by reference. It basically has the same meaning as the '&' but
<the '@' can be used on non-lvalues such as constants and expressions.
<char c;
< func(&c, @20);
<will cause a pointer to a temporary copy of an int with a value of 20
<to be passed to the function.
Sounds silly to me. Why not just extend the compiler to have &20 mean
just that? The @ is not necessary if such behavior is desired.karl@haddock.ima.isc.com (Karl Heuer) (10/28/89)
In article <14811@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >>The best solution would be to have /* /* */ generate a warning. > >Again -- this is a common usage in config.h type files. > /* #define BSD4_3 /* for BSD 4.3 systems */ The best solution is for this to be an option. Then people who use the above grotesqueness can disable the warning, and those of us who use a more sensible style can enable it and have the benefit of the improved error checking. The same applies to `if (a=b)'. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
condict@cs.vu.nl (Michael Condict) (11/09/89)
In article <136@csnz.co.nz> paul@csnz.co.nz (Paul Gillingwater) writes: >In article <11463@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >>The most reasonable one was to add //-comment-to-end-of-line style >>comments. ... However, it was quite a bother >>when our //-ed code had to be compiled by a compiler that hadn't >>received this hack! > >sed -d ?^//? < foo.c > tmp.c ; cc tmp.c -o foo I get a little irritated when people post pithy little chunks of code or scripts of shell sessions with no commentary as a reply to a question or to refute a claim that something is hard to do -- it seems like an unnecessarily smug response. It is particulary irritating when the code is wrong. I don't know what the -d flag does in your sed command (it's not accepted by any version I've seen), but in order for the above sed command to work correctly, it would have to mean something like: ``ignore ^ at beginning of following pattern argument, pretend it has ".*$" at the end of it and delete substrings of any line that match the (assumed) pattern, but only if the substring is not part of any C quoted string, char or /**/-type comment''. Seriously, it seems that you were making an attempt to do the following: sed -e '?^//.*$?d' . . . using some bizarre abbreviation in your sed, which maps ``-d ?pat?'' to ``-e ?pat?d''. This won't work for two reasons: (1) Doug Gwyn never said that the comments had to start in column one. (2) Therefore, they may be preceded by C quoted strings, char constants or /**/-type comments that happen to contain the string //. Even if they are restricted to column one, what about: /* This comment contains what looks // like a double-slash comment but is not. */ int f(x) int x { return x+1; } The problem can be correctly handled by a sed script, but one considerably more complicated then the one you show. -- Michael Condict condict@cs.vu.nl Vrije University Amsterdam
gwyn@smoke.BRL.MIL (Doug Gwyn) (11/09/89)
In article <136@csnz.co.nz> paul@csnz.co.nz (Paul Gillingwater) writes: -In article <11463@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: ->The most reasonable one was to add //-comment-to-end-of-line style ->comments. ... However, it was quite a bother ->when our //-ed code had to be compiled by a compiler that hadn't ->received this hack! -sed -d ?^//? < foo.c > tmp.c ; cc tmp.c -o foo Sorry, that's completely wrong. I had to write a decidedly non-trivial program to do the job. It was based on an FSA.
cpcahil@virtech.uucp (Conor P. Cahill) (11/09/89)
In article <136@csnz.co.nz>, paul@csnz.co.nz (Paul Gillingwater) writes: > In article <11463@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > >The most reasonable one was to add //-comment-to-end-of-line style > >comments. ... However, it was quite a bother > >when our //-ed code had to be compiled by a compiler that hadn't > >received this hack! > > sed -d ?^//? < foo.c > tmp.c ; cc tmp.c -o foo Just a few problems with this solution: 1. It's a pain in the *ss to change all the makefiles 2. Error messages from the cc tmp.c will point to the wrong line numbers 3. A source level debugger would require the tmp.c file to stay around which would require you the use a different name for each file. If you chose to add a letter to the begining (like Tfoo.c), you run the risk of making a file name that is too long for the system. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
rick@conexch.UUCP (Rick Ellis) (11/25/89)
In article <1989Oct28.005308.11463@virtech.uucp> cpcahil@virtech.uucp writes: >Your example should not generated an error in any sane implementation. >Contents of string constants have never been parsed for comment delimeters. In many C compilers there is a switch to allow nested comments. This allows you to comment out large blocks without worrying about imbedded comments. Of course it's much easier to just use #ifdef COMMENT.
pausv@sssab.se (Paul Svensson) (11/28/89)
In article <1989Oct28.005308.11463@virtech.uucp> cpcahil@virtech.uucp writes: >Contents of string constants have never been parsed for comment delimeters. Well, how about this then: #ifdef notdef "!%()[]/*", #endif I know at least one compiler that fail to realize that this does not start a comment. -- Paul Svensson _ /| - Every absurdity needs a champion to defend it - SM5SJS \'o.0' Scandinavian System Support Fax: +46 13 115193 paul@sssab.se =(___)= Box 535 _ Phone: +46 13 111660 sunic!sssab!paul U S-581 06 Linkoping, Sweden Home: +46 13 121021
mark@jhereg.Minnetech.MN.ORG (Mark H. Colburn) (12/01/89)
In article <1989Nov28.145229.27060@sssab.se> pausv@sssab.se (Paul Svensson) writes: >#ifdef notdef > "!%()[]/*", >#endif > >I know at least one compiler that fail to realize that this does not >start a comment. Get a new compiler. That one is busted... -- Mark H. Colburn mark@Minnetech.MN.ORG Open Systems Architects, Inc.
battle@alphard.cs.utk.edu (David Battle) (12/14/89)
In article <426@jhereg.Minnetech.MN.ORG> Mark H. Colburn writes: >In article <1989Nov28.145229.27060@sssab.se> [...] (Paul Svensson) writes: > >#ifdef notdef > > "!%()[]/*", > >#endif > > > >I know at least one compiler that fail to realize that this does not > >start a comment. > > Get a new compiler. That one is busted... What SHOULD the following program do? Why? #ifdef NOTDEF /* #endif #define COMMENT_NOT_EFFECTIVE 1 #ifdef NOTDEF */ #endif int main(int argc, char **argv) { #ifdef COMMENT_NOT_EFFECTIVE (void) printf("#ifdef takes precidence.\n"); #else (void) printf("/* takes precidence.\n"); #endif return 0; } -David L. Battle battle@battle.esd.ornl.gov battle@utkvx2.BITNET
henry@utzoo.uucp (Henry Spencer) (12/16/89)
In article <1501@utkcs2.cs.utk.edu> battle@alphard.cs.utk.edu (David Battle) writes: >What SHOULD the following program do? Why? In ANSI C, the answer is clear: deletion of comments is done before preprocessing. In pre-ANSI C, the answer is mumble mumble mumble and you'd better not depend on it either way. -- 1755 EST, Dec 14, 1972: human | Henry Spencer at U of Toronto Zoology exploration of space terminates| uunet!attcan!utzoo!henry henry@zoo.toronto.edu