ANSI C: CPP predefined constants vs. <whoami.h>

[Stew Rubenstein]

Re Keld Simonsen's long message advocating the use of whoami.h:

I have much more experience with C on vms than on unix, but I can't
count the number of times I cursed the people who forced me to recompile
their software because the system name or some pathname was compiled
into the program.

In a perfect world, we would all have sources for all the programs we
ran, and compilers for all the languages in which they are written.
Unfortunately, this is not always the case!  Even when it is, it is a
pain to have to recompile the program (sometimes discovering a missing
include file or other piece) when installing it.

On VMS, there is a wonderful facility for dealing with this:  the
logical name.  For you unix folks, I guess this would be called a
systemwide environment variable.  You just do:

	$ DEFINE/SYSTEM SITE_NAME "MYNAME"
	$ DEFINE/SYSTEM PKG_LIBRARY DISK:[DIR]

and move the executable to the public program library.

Before I don my asbestos suit, I should point out that this is one of
the features that I consider to be good about VMS -- but I'm not so
closeminded that I refuse to admit it has \something/ worth copying...

And yes, I know this probably doesn't belong in net.lang.c, but having
just spent time trying to recompile some things just because they had a
compiled-in site name, I was feeling sensitive about the whoami.h topic.
And, for the record, I don't see why it is inappropriate to have
predefined symbols to deal with different operating systems.  Nor do I
see how moving them to whoami.h solves the problem.  Realistically,
portable software will have to know about the symbols defined on each
system for which it is ported.

And finally (for those who have waded through the above), a constructive
suggestion.  I can see how you might be worried about some future
preprocessor usurping your symbols.  The way to deal with this is to
adopt a convention for feature- and system-dependent symbols.  For
example, adopt the convention that symbols starting with sys_ or cpu_ be
reserved for the compiler.  Then SUN Microsystems can define sys_sun and
cpu_m68000, and VAX/VMS can define sys_vms and cpu_vax, and as long as
you avoid symbols of this type, you will be safe.

This need not cause every program in the world to break -- just adopt
this as a suggestion for future compiler implementors, and add them to
existing compilers when convenient.  As future compilers and cpus take
over, the convention will be more widely observed.
-- 
-----------------------
Stew Rubenstein     UUCP: ihnp4!harvard!stew
Harvard Chemistry   ARPA: stew at harvard