diamond@csl.sony.co.jp (Norman Diamond) (11/21/89)
This question is also a repost. It seems to have gotten lost between kddlabs and the rest of the world, and never got a reply. According to section 3.8.2, page 89 lines 14 to 17, if pp-tokens are macro replaced in an #include directive, the implementation might choose to combine preprocessor tokens between a pair of " characters by, for example, putting a space between each pair of preprocessor tokens. (An implementation might do this because it always puts spaces between preprocessor tokens, because two adjacent preprocessor tokens of - - are not supposed to become a single real token --.) Therefore in the example on page 93, line 17 might not yield the result shown on line 23. Line 23 is certainly a possibility, but another possibility, depending on the implementation, is: #include "vers2 .h" with an imbedded space. I must ask again which carries more weight, the stated rules or the examples. -- 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".
henry@utzoo.uucp (Henry Spencer) (11/23/89)
In article <11160@riks.csl.sony.co.jp> diamond@ws.sony.junet (Norman Diamond) writes: >I must ask again which carries more weight, the stated rules or the >examples. I must reply again :-), if you read section 1.4 very carefully, you will discover that the examples are technically not part of the standard. -- 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
gwyn@smoke.BRL.MIL (Doug Gwyn) (11/23/89)
In article <1989Nov22.222413.3874@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <11160@riks.csl.sony.co.jp> diamond@ws.sony.junet (Norman Diamond) writes: >>I must ask again which carries more weight, the stated rules or the >>examples. >I must reply again :-), if you read section 1.4 very carefully, you will >discover that the examples are technically not part of the standard. But that's beside the point. The preprocessing examples were reviewed VERY carefully by numerous implementors, and we do not believe there are any errors in them in the final draft. Therefore if you think the actual specification conflicts with the examples, the odds are good that you're not interpreting the specification correctly. The use of a natural language (such as English) for such a technical specification always opens up the possibility of misinterpretation, because words denote concepts and there is no direct way to transfer a concept from one human being to another; independent parallel conceptualization must be performed by the recipient. The best the communicator can do is to attempt to guide the recipient's thought processes, but there is no way to guarantee the result. We just had another example of this in the comp.std.unix newsgroup, where someone was attempting to read IEEE Std 1003.1-1988 like an unthinking automaton and blindly apply what he thought it literally said to arrive at erroneous conclusions. Of course, he had to apply some degree of interpretation even to get that far, but he argued that no interpretation should be required. I think that represents a misunderstanding of how to read technical information.
diamond@csl.sony.co.jp (Norman Diamond) (11/25/89)
In article <11160@riks.csl.sony.co.jp> I asked about token pasting in the #include directive, and then snidely remarked, >>I must ask again which carries more weight, the stated rules or the >>examples. My real question does not appear to have been answered. Only the snide subsidiary question seems to matter. That's what I get from posting to usenet, eh? In article <1989Nov22.222413.3874@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >I must reply again :-), if you read section 1.4 very carefully, you will >discover that the examples are technically not part of the standard. Yes, but in other cases it has been determined that the examples properly reflect the committee's intent, while the words do not reflect the committee's intent. And we are supposed to obey their intent instead of their words. The conclusion to my real question seems obvious now. The pasting of tokens in the #include directive is implementation-defined, but all implementations must define it in the same manner as the example (which in fact requires a form of pasting which conflicts with the rules for preprocessing everything else in a source program). -- 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".