maart@cs.vu.nl (Maarten Litmaath) (09/23/89)
ok@cs.mu.oz.au (Richard O'Keefe) writes:
\... #if 0
\... ...
\ #endif 0
\(a) ^ this token is not legal in dpANS C; V.3 tends not to like it
What!? The rest of the line isn't ignored? And what was the very good reason
the ANSI committee decided so?
\(b) You should not use this technique to comment out text in a C program; new
\C compilers are allowed to complain about mismatched quotes when they see
\"don't" and other such text, and some _do_.
I remember the discussion, but I don't recall the very good reason (here we
go again) why those compilers could complain. Quality of implementation?
That's another point for Sun, 'cause their cpp works. :-)
\ You're going to laugh, but how about using the Bourne shell as a
\condition processing facility? E.g.
\ if [ ... ] ; then
\ cat <<'EndOfPart'
\ any old text -- almost
\ EndOfPart
\ else
\ # equivalent of 'include'
\ cat foo.inc
\ fi
Great! However, use `test' instead of `[' if portability is an issue. :-(
--
creat(2) shouldn't have been create(2): |Maarten Litmaath @ VU Amsterdam:
it shouldn't have existed at all. |maart@cs.vu.nl, mcvax!botter!maartguy@auspex.auspex.com (Guy Harris) (09/24/89)
>ok@cs.mu.oz.au (Richard O'Keefe) writes: >\... #if 0 >\... ... >\ #endif 0 >\(a) ^ this token is not legal in dpANS C; V.3 tends not to like it > >What!? The rest of the line isn't ignored? And what was the very good reason >the ANSI committee decided so? From the Rationale (presented without comment - I neither endorse nor reject their rationale, I merely present it): Various proposals were considered for permitting text other than comments at the end of directives, particularly "#endif" and "#else", presumably to label them for easier matchup with their corresponding "#if" directives. The Committee rejected all such proposals because of the difficulty of specifying exactly what would be permitted, and how the translator would have to process it. Three notes: 1) V.3 "tends not to like it", but merely spits out a warning - the code will still compile. 2) If you put "/*" and "*/" around the token, the resulting text is legal (assuming, of course, that there's no "*/" in the token, etc.). 3) If there already exist compilers that disallow extra tokens like that, one should consider replacing them with comments *anyway*. >\(b) You should not use this technique to comment out text in a C program; new >\C compilers are allowed to complain about mismatched quotes when they see >\"don't" and other such text, and some _do_. > >I remember the discussion, but I don't recall the very good reason (here we >go again) why those compilers could complain. Quality of implementation? >That's another point for Sun, 'cause their cpp works. :-) Sun's "cpp" is derived from various versions of the AT&T preprocessor (the precise version depends on the SunOS release); the credit doesn't go to Sun, by and large, for it working in that particular case - you'll probably find most, if not all, other Reiser-based "cpp"s (well, "cpp"s based on Reiser's "cpp", not based on Reiser himself, but you knew what I meant :-)), handle that particular case in the fashion you desire. The SunOS 4.x "cpp" is, BTW, based on the S5R3 "cpp", but the warning for extra tokens at the end of "#else"/"#endif" was put under the control of a "-p" (for "portability") flag to "cpp" (used, as I remember, only by the S5-environment "lint" when it is given the "-p" flag) because the practice was so widespread.
henry@utzoo.uucp (Henry Spencer) (09/24/89)
In article <3346@solo12.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >\ #endif 0 >\(a) ^ this token is not legal in dpANS C; V.3 tends not to like it > >What!? The rest of the line isn't ignored? And what was the very good reason >the ANSI committee decided so? Because only a few compilers ignored it, and the rest didn't, and there didn't seem to be any good reason to perpetuate this irregular accident of certain implementations. Try `#endif /* 0 */' if you want to put a comment in. >\(b) You should not use this technique to comment out text in a C program; new >\C compilers are allowed to complain about mismatched quotes when they see >\"don't" and other such text, and some _do_. > >I remember the discussion, but I don't recall the very good reason (here we >go again) why those compilers could complain... A good many compilers tokenize text before doing anything else with it, even preprocessing. To avoid rendering all those implementations illegal, it has to be possible to do this. The preprocessor was never specified clearly enough to say that these implementations are wrong. -- "Where is D.D. Harriman now, | Henry Spencer at U of Toronto Zoology when we really *need* him?" | uunet!attcan!utzoo!henry henry@zoo.toronto.edu