minow@decvax.UUCP (Martin Minow) (10/10/87)
May a comment follow the file specifier in an #include statement? The August 3 '87 Draft Standard defines #include as #include pp-tokens new-line While comments are syntactically "white-space characters", the Standard specifically states that only space and horizontal-tab may appear within a preprocessing statement (sec 3.7.1, p 76, line 34-36). For that matter, may a comment appear in any p.p. statement such as: #define BEAUTY TRUE /* All you need to know */ What is the modtivation for the "only space and tab" constraint? Martin Minow decvax!minow
gwyn@brl-smoke.ARPA (Doug Gwyn ) (10/10/87)
In article <169@decvax.UUCP> minow@decvax.UUCP (Martin Minow) writes: >May a comment follow the file specifier in an #include statement? Yes. The only constraint is that "/*" embedded within the header or file name is considered to yield "undefined" behavior. There is no problem with a comment outside the name. >While comments are syntactically "white-space characters", the Standard >specifically states that only space and horizontal-tab may appear within >a preprocessing statement (sec 3.7.1, p 76, line 34-36). That's because, as explained under 2.1.1.2 Translation Phases, each comment has already been converted to one space character at this point. >For that matter, may a comment appear in any p.p. statement such as: > #define BEAUTY TRUE /* All you need to know */ Yes, of course. >What is the modtivation for the "only space and tab" constraint? There didn't seem to be any reason to require implementations to support embedded vertical-motion whitespace or backspaces in preprocessing directives, and it was easy to envision possible problems in some situations. If you think this needs to be generalized, it would behoove you to come up with convincing reasons.
chapman@ihuxy.ATT.COM (Chapman) (10/17/87)
In article <169@decvax.UUCP>, minow@decvax.UUCP (Martin Minow) writes: > For that matter, may a comment appear in any p.p. statement such as: > #define BEAUTY TRUE /* All you need to know */ Whether or not a comment may appear after a #define, what's the worst that can happen? The comment will become part of the definition, but will be harmless wherever it is substituted. (Right, all you C wiz's?)
ado@elsie.UUCP (Arthur David Olson) (10/18/87)
In article <2205@ihuxy.ATT.COM>, chapman@ihuxy.ATT.COM (Chapman) writes: > > #define BEAUTY TRUE /* All you need to know */ > > Whether or not a comment may appear after a #define, what's the worst that > can happen? The comment will become part of the definition, but will be > harmless wherever it is substituted. No--the worst thing that can happen is that the preprocessor claims the code is invalid because of the comment in the directive, meaning that you can't compile the code. While it's true that the "translation phases" description in the draft Standard gives a semblance of a guarantee that comments may appear within preprocessor directives, implementors may well have forgotten that guarantee by the time they get to the preprocessor section of the standard. I've previously suggested that where the standard limits the white space characters that may appear in directives to space and horizontal-tab the language should be changed to read horizontal-tab and space (including space characters that replace comments) but the suggestion has not (yet :-) been taken. And to stave off some followups: yes, comments do appear within directives both in the Rationale and in examples within the Standard itself--and remember that neither the Rationale nor examples (nor footnotes) are "officially" part of the Standard. -- ado@vax2.nlm.nih.gov ADO, VAX, and NIH are trademarks of Ampex and DEC.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (10/19/87)
In article <7517@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: >While it's true that the "translation phases" description in the draft >Standard gives a semblance of a guarantee that comments may appear within >preprocessor directives, implementors may well have forgotten that guarantee >by the time they get to the preprocessor section of the standard. I think the consensus of the X3J11 Committee is that anyone who forgets about the Translation Phases portion of the specification cannot possibly produce a conforming implementation. Conformance test suites are sure to catch such an error.
lewisd@homxc.UUCP (David Lewis) (10/19/87)
In article <2205@ihuxy.ATT.COM>, chapman@ihuxy.ATT.COM (Chapman) writes: > In article <169@decvax.UUCP>, minow@decvax.UUCP (Martin Minow) writes: > > For that matter, may a comment appear in any p.p. statement such as: > > #define BEAUTY TRUE /* All you need to know */ > Whether or not a comment may appear after a #define, what's the worst that > can happen? The comment will become part of the definition, but will be > harmless wherever it is substituted. (Right, all you C wiz's?) We hit a major snag with the reverse of this situation: commenting out preprocessor statements: /* commented out #define BEAUTY TRUE */ Didn't realize that the pre-processor didn't understand comments. This happened on a VAX; is it generally the case that BEAUTY will be defined? -- David B. Lewis {ihnp4,allegra,ulysses}!homxc!lewisd 201-615-5306 EDT
henry@utzoo.UUCP (Henry Spencer) (10/20/87)
> I think the consensus of the X3J11 Committee is that anyone who forgets > about the Translation Phases portion of the specification cannot possibly > produce a conforming implementation... Speaking as someone who has experimented with implementing an X3J11 draft, it simply is not possible to understand the fine points of the preprocessor semantics without reference to the Translation Phases discussion. The interactions between things like comments, trigraphs, #define, etc. just are not precisely specified anywhere else. -- PS/2: Yesterday's hardware today. | Henry Spencer @ U of Toronto Zoology OS/2: Yesterday's software tomorrow. | {allegra,ihnp4,decvax,utai}!utzoo!henry
ron@topaz.rutgers.edu (Ron Natalie) (10/20/87)
After getting screwed a number of times "commenting out" code I have
banned it. Code is turned off by using the conditional compile feature
of the language which was designed to do this, for example
#if 0
...
#endif
-Ron