Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!brl-adm!brl-smoke!smoke!gwyn@BRL.ARPA
From: gwyn@BRL.ARPA (VLD/VMB)
Newsgroups: net.lang.c
Subject: Re:  Draft standard questions
Message-ID: <2244@brl-smoke.ARPA>
Date: Tue, 15-Jul-86 09:29:43 EDT
Article-I.D.: brl-smok.2244
Posted: Tue Jul 15 09:29:43 1986
Date-Received: Wed, 16-Jul-86 03:22:55 EDT
Sender: news@brl-smoke.ARPA
Lines: 30

__STR__ and __CAT__ were suggested by Tom Plum in a late-night
working session to resolve the remaining preprocessor issues,
after general committee rejection of Dave Prosser's innovative
proposals for prefix concatenation, stringize, and charize
operators.  These facilities have to be considered in the light
of a total specification of the phases of translation, which
involves such questions as whether the result of macro
substitution can be allowed to result in pasting of stuff on the
left of what was the current working set of tokens and rescan
of the result of that pasting.  Much of the difficulty comes
from an attempt to accommodate macro substitution on #include
lines, which some vendors support and claim their customers
really need for portability reasons (remember that different
OSes have different ideas of file names).

The preprocessor experts (I'm not one of them) seemed to think
that __STR__ and __CAT__ built-in macros was the best solution
under the constraints.  However, the committee members had not
had sufficient time to consider this proposal and didn't want
to risk adopting it without sufficient study.

The Reiser CPP is definitely out.  It can be modified with some
effort to conform with the current X3J11 proposal, but it has
too many technical problems to insist on everyone duplicating
its behavior.  In particular, many excellent C compilers handle
preprocessing as part of the general lexical analyzer rather
than as a totally separate pass; such tokenizing approaches
have to be accommodated by the standard.

I think Donn Seeley intends to upgrade the 4.nBSD CPP to X3J11.