Token pasting in #include directive

[Doug Gwyn]

In article <11188 at riks.csl.sony.co.jp> diamond at ws.sony.junet (Norman Diamond) writes:
>In article <11160 at 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?

I don't know WHY you post the questions you do.  They're often worded
like you're trying to show your intellectual superiority.  That may be
one of the reasons you elicit hostile responses.

>In article <1989Nov22.222413.3874 at utzoo.uucp> henry at 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.

You are misrepresenting previous discussions.  Both the "words" (formal
specification) and the examples reflect the committee's intent.  In some
cases referring to the examples can help one understand the words, and
in practically all cases you have to refer to the words to understand
the examples.  The examples are not provided as a tutorial, but rather
to illustrate the application of the rules.

Henry's comment was beside the point.  We believe all the examples to be
correct.

No matter WHAT interpretation you personally place on the words, it is
inescapable that you're applying an interpretation of some sort,
involving your particular background, knowledge of English usage,
analogies with other technical writing, expectations about programming
languages, and so on.  X3J11 tried their best to anticipate possible
ambiguity and misunderstanding, and in fact provided examples and a
Rationale document to help guide readers of the Standard; however,
obviously they could not possibly guarantee that NObody would read the
specification as saying something unintended or draw wrong conclusions
from the specification.  This is simply an inevitable property of
language as such, and does not necessarily indicate a deficiency in
the specification.

I've seen a lot of programming specifications, and in my opinion X3.159
is among the very best.  That doesn't mean that it is easy to fully
comprehend nor that it is impossible to misunderstand it.  It may even
have a few genuine technical errors that went undetected through three
public reviews, but you're not pointing out cases of those, merely
(in my opinion, fairly perverse) ways of misinterpreting correct specs.

>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).

No, both examples of macro replacement within an #include are correct
(I manually checked them), and all conforming implementations must
reproduce that behavior exactly.  Section 3.8.2 is quite explicit
about the processing of all three forms of #include.  There is nothing
implementation-defined about the examples, and the normal pasting rules
do apply.