azeemk@microsoft.UUCP (Azeem Kahn) (12/06/89)
This question deals with the implementation of #ifdef. Consider the following: #define VAR #ifdef VAR ... ... #else /* #endif */ #endif VAR is defined and hence the #else is the inactive segment. Now should the preprocessor match the #else with the first or the second #endif? In other words, does the preprocessor have to look at the lines in the inactive segment for comments, unclosed qoutes etc. OR should it disregard everything in the inactive segment and just keep looking for a matching #endif to satisfy the nesting. I want to know what the standard says about this. I am not interested in what some systems do and others don't. Thanks for any info. -azeem.
gwyn@smoke.BRL.MIL (Doug Gwyn) (12/06/89)
In article <9326@microsoft.UUCP> azeemk@microsoft.UUCP (Azeem Kahn) writes:
-#else
-/*
-#endif
-*/
-#endif
-VAR is defined and hence the #else is the inactive segment. Now
-should the preprocessor match the #else with the first or the
-second #endif? In other words, does the preprocessor have to look
-at the lines in the inactive segment for comments, unclosed qoutes
-etc. OR should it disregard everything in the inactive segment and
-just keep looking for a matching #endif to satisfy the nesting.
This is answered in section 2.1.1.2, "Translation phases".
Comments are replaced by spaces before preprocessing directives
are executed.
Thus there is no "first #endif"; it is commented-out.henry@utzoo.uucp (Henry Spencer) (12/07/89)
In article <9326@microsoft.UUCP> azeemk@microsoft.UUCP (Azeem Kahn) writes: >/* >#endif >*/ >I want to know what the standard says about this. I am not interested >in what some systems do and others don't. Section 2.1.1.2, Oct 1988 draft (still current except for wording changes), says comment elimination happens first, so that #endif is never seen. In case people are interested, 2.1.1.2 defines eight translation phases, to specify the order in which things happen. Abbreviated, they are: 1. Any funny character-code translations are done, and trigraphs interpreted. 2. Newlines immediately preceded by backslashes vanish. 3. Source turns into preprocessing tokens; comments vanish. 4. Preprocessing, including running #included files through phases 1-4. 5. Character constants and string literals translated to target character set, including interpretation of escape sequences. 6. Concatenation of adjacent string literals. 7. White space vanishes, preprocessing tokens become tokens; compilation. 8. Linking. In case anyone hasn't heard about preprocessing tokens, they are pretty much ordinary tokens except that white space and newlines are tokens (because they matter to the preprocessor in certain situations) and the syntax of numbers is rather vague and general (because one of the putrid operators involved in macro expansion -- whose only virtue is that it's a bit less putrid than the Reiserism that it replaces -- can glue two pptokens together into one, so one cannot be too fussy about token syntax until after such abominations have finished their dirty work). -- 1233 EST, Dec 7, 1972: | Henry Spencer at U of Toronto Zoology last ship sails for the Moon. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu