Token pasting in #include directive
Doug Gwyn
gwyn at smoke.BRL.MIL
Tue Nov 28 08:25:43 AEST 1989
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.
More information about the Comp.std.c
mailing list