Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!mailrus!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Token pasting in #include directive
Message-ID: <11693@smoke.BRL.MIL>
Date: 27 Nov 89 21:25:43 GMT
References: <11160@riks.csl.sony.co.jp> <1989Nov22.222413.3874@utzoo.uucp> <11188@riks.csl.sony.co.jp> <11685@smoke.BRL.MIL> <11193@riks.csl.sony.co.jp>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 48

In article <11193@riks.csl.sony.co.jp> diamond@ws.sony.junet (Norman Diamond) writes:
>In article <11685@smoke.BRL.MIL> gwyn@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.