Token pasting in #include directive

[Doug Gwyn]

In article <11193 at riks.csl.sony.co.jp> diamond at ws.sony.junet (Norman Diamond) writes:
>In article <11685 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
>Because the standard says certain things that do not make much sense,

Just because they don't make sense to YOU does not necessarily mean
that they don't make sense.

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

Perhaps the reason you have to keep waiting is that I have not been
convinced that the Standard has a problem in this area.  Section 2.1.2
makes the initialization model pretty clear, and combined with the
obvious notion that a variable holds a single value at a time it
precludes multiple simultaneous initializers.

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

Which is irrelevant since it is the THIRD form of #include (involving
neither "" nor <> until after macro replacement is complete) that we
are concerned with.

>The method by which the '2' gets pasted to the '.' is implementation
>defined, according to the "words" of the standard.

NO, it is NOT.  Macro replacement and stringizing is well defined and
does not permit variation in this respect.

>According to the example, all implementations must define this
>pasting in the same manner.

Right.  Also according to the words in the Standard.

>According to Doug Gwyn, "implementation-defined" does not mean
>implementation-defined.

No, that's according to you.  This is NOT NOT NOT implementation
defined, as I've said before.

>And you wonder why I'm hostile?

Probably has something to do with not listening to what others are
saying.