ANSI C and the C Pre-Processor

[Henry Spencer]

> ............ However, this idea is being extended to include strings and
> character constants as tokens that don't get scanned for replacement text.

K+R, section 12.1:  "Text inside a string or a character constant is
not subject to replacement."  In other words, this is not something new:
the language has always been specified to behave that way.

> ........................................ However, I have seen plenty of
> programs which use some of the following constructs:
> 
> #define libpath(x)		"/usr/lib/x"
> #define CTRL(x)			('x'&037)
> #define PRINT1(format,arg)	printf("arg=%format.\n", arg);

Such programs are broken and unportable.  Most non-Unix C compilers have
been implemented "by the book", which means that none of the above things
will work on them unless the implementors had a lot of Unix experience
or had a Unix system to compare against.

> The questions are: Should this change be endorsed? If so, what should be
> done to bring back the lost functionality? If not, how would you make CPP
> more regular in its scanning rather than that which is the de-facto standard
> from Reiser?

Of course it should be endorsed, since it's not really a change at all.
The standard is the documentation, not Reiser's code.

As for what should be done to bring back the lost functionality...  the
ANSI C folks have basically said "if you want a general-purpose macro
processor, use m4".  The programs that this "change" will break are
broken already, and should be fixed to do it right.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry