Standardization questions (cpp mostly)

trt at rti-sel.UUCP trt at rti-sel.UUCP
Sat Oct 6 00:37:16 AEST 1984


Here is a repeat request for a simple but important change to cpp.

MOTIVATION
The number of predefined CPP variables on systems worldwide
is growing weekly.  The following innocent program fails to compile
on our Gould system:
	grumble()
	{
		int sel;

		sel = selectone();
		...
	}
The reason is that 'sel' is a predefined CPP variable!
(It is quite difficult for a novice user to figure out what is going wrong.)
Other people will find similar strange problems if they use
variables named 'pyramid', 'sun', and so on.  This is ridiculous!

WHAT IS WRONG
A predefined variable is produced with explicit code in cpp,
with the '-Dvax' argument to cpp, or with '#define vax 1'
The result is that 'vax' evaluates to '1', which is fine if
people want to say '#ifdef vax' or (gag me) '#if vax'
but not so hot if you want to compile a portable (hear hear!)
program that happens to use 'vax' as a variable.

THE FIX
We should return to the old days when vax was really 'vax',
unix was really 'unix', and small furry creatures were still single.
Here is a weak attempt at how it might be worded:
	The effect of '#define foo foo' and also '-Dfoo' as an option
	will be to make 'foo' defined and to evaluate to itself.
	Subsequently, foo and defined(foo) will both evaluate to 1
	within a #if, foo will be considered defined within a #ifdef
	or #ifndef, and foo will have no special meaning elsewhere.

DISCUSSION
This change is minor and would not break any existing programs.
People need no longer live in fear of the 'printf' machine
that is to be announced early next year.

I am not sure if '#define unix unix' should be handled as
a special case (ordinarily it would result in a cpp loop),
or if there is a general fix.  For example, what about
    #define sun (sun|sel)    /* avoids changing '#if sun' everywhere */
I suppose that is a fairly disgusting example.
I am sure the Standards committee can figure something out,
so long as I can continue to use a variable named 'os' without
worrying about whether some compiler somewhere has already spoken for it.
	Tom Truscott



More information about the Comp.lang.c mailing list