Token pasting in #include directive

[Norman Diamond]

In article <11685 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:

>I don't know WHY you post the questions you do.

Because the standard says certain things that do not make much sense,
and I try to find out what it should have said, along with the
implication that it should be made to say what it should have said.

>They're often worded
>like you're trying to show your intellectual superiority.

Gee, I'm sorry if technical analysis and efforts to obey the rules are
intellectually superior to the development and coding of the rules.
I was not trying to show such superiority.

>That may be
>one of the reasons you elicit hostile responses.

Actually the responses did not seem particularly hostile, but I have a
tendency to become hostile to dishonest replies.  Such as suggestions
that the standard says things that it does not say.  Such as blaming
English for ambiguity in statements where the authors made absolutely
no attempt to begin writing those statements, i.e. where the standard
says nothing.

>From one of my postings:

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

I am not.

>Both the "words" (formal
>specification) and the examples reflect the committee's intent.

In some cases it was determined that the "words" do not reflect the
committee's intent.

>It may even
>have a few genuine technical errors that went undetected through three
>public reviews,

It certainly does.

>but you're not pointing out cases of those

I certainly did.  So did several others, and they received the same
sort of dishonest answer from you.  For example, I have been watching
for you to apologize and admit that the standard does not limit an
identifier with external linkage to having only one initialization
(when the identifier is never used in an expression).  The poser of
that error seems less determined than I am to follow up on these errors.

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

Page 89, lines 14 to 17:  The method by which a sequence of
preprocessing tokens between a < and a > preprocessing token pair or a
pair of " characters is combined into a single header name preprocessing
token is implementation-defined.

Page 93, line 17:  #include xstr(INCFILE(2).h)

Page 93, line 23:  #include "vers2.h"

The method by which the '2' gets pasted to the '.' is implementation
defined, according to the "words" of the standard.  According to the
example, all implementations must define this pasting in the same
manner.  According to Doug Gwyn, "implementation-defined" does not
mean implementation-defined.

And you wonder why I'm hostile?

-- 
Norman Diamond, Sony Corp. (diamond%ws.sony.junet at 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".