🚀 go-pugleaf

Newsgroups: net.bugs,net.lang.c
Subject: Bug (?) in C preprocessor

Note the following behaviour of the C preprocessor (V7 and System V):

#define FRED jim
#define QUOTE(x) "x"

QUOTE(FRED)
______________________

	The output of the C preprocessor when fed this fragment is

"FRED"

	Obviously, it is applying the QUOTE() macro on FRED,
before re-scanning and since "FRED" is then quoted, no substitution
takes place. If the order of evaluation were the other way, ie to
evaluate what is inside the parentheses first, before applying the
macro QUOTE to it, the result would be

"jim"

	(which is actually what I wanted when I discovered this). I
suggest that this order of evaluation is more sensible, and conforms
more closely to what C itself (and almost all other programming
languages) does (evaluating expressions from within the most deeply
nested level of parentheses first).
	I will probably be changing the preprocessor here to do this,
but would like to see what the net thinks first. Has anyone else
come across this problem?

Aside:
	If this change is made, then it allows constructs like

#define QUOTE(x) "x"
#include QUOTE(NAME.h)

	where NAME is defined to the preprocessor on the command line
at compile time. Whether this is a terrible thing to do or not is
another story. I wanted it so I could modify maketerms.c in the nroff
system so that I could make terminal driving tables one at a time (a
single "make" at the top of our source directory would then install
a new terminal driving table in /usr/lib/terms without having to create
a whole set. Also, new driving tables could then be added without
modifying maketerms.c.


					Stephen Frede
					Dept. Computer Science
					University of NSW
					P.O. Box 1
					Kensington 2033
					AUSTRALIA


				...!decvax!mulga!stephenf:elec70b