ANSI C and the C Pre-Processor

[Henry Spencer]

> ....................  K&R was never clear on this point - its
> wording on this point (and others) was ambiguous.  That is,
> a perfectly viable interpretation, taken by Reiser, was that
> strings in the token sequence could be scanned for parameters.

Point taken, K&R was never entirely clear on this, but it *sounded*
clear enough that a lot of people just assumed "no substitution
inside strings".  Including a lot of implementors.

> The problem is that K&R is *not* a standard.  If it was, we wouldn't
> need X3J11...

On the contrary, ask most C compiler implementors outside Bell and they
will tell you that K&R is the standard they worked from.  It is true
that K&R is not precise enough or complete enough to be an ANSI-quality
standard, but anyone who denies that K&R has been a *de facto* standard
for quite some time is kidding himself.  A poor one, yes, but a standard.

> No-one is asking for a full blown macro processor, just that subset
> that is really useful for C programs...

The trouble is that "really useful" is a subjective judgement.  My
personal view is that both token concatenation and in-string substitution
are useless junk.  I am quite aware that other people feel otherwise.
Anyone who has looked at the implementation of the S statistics language
has some idea of just how far "really useful" can be pushed.  (Much of
the S stuff needs *several passes* through m4 before compilation!)  In
practice, one has to draw the line somewhere.  The question is not "is
this feature useful?" but "is this feature useful *enough* to force
*everyone* to implement it?".  Saying "if you want fancy stuff, use m4"
is not a cop-out, it is a statement that the committee is not going to
solve all the world's problems.

> Seems to me that in this case, adopting the Reiser interpretation
> is the better thing to do.  Document it clearly, so people aren't
> trapped, and that should end the problems.

My impression is that the committee's biggest problem with this is that
retrofitting the Reiser interpretation into existing compilers is not
necessarily easy.  A good many compilers do *not* do the preprocessing
as a separate text-manipulation step first; their "preprocessors" are
integrated into the scanner, or following it.  Pulling tokens apart
again into text, and then reassembling them, isn't trivial.  The current
committee notion (substitution only on whole strings) avoids much of the
complexity of this.

One can argue that issues of current implementation are not significant,
that the future users should be the primary consideration.  This ignores
a nasty pragmatic consideration:  if the standard is going to fly,
standard-conforming implementations are going to have to be common.  It
would really be nice if existing compilers didn't have to be rewritten
from scratch.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry