Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site harvard.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!wjh12!harvard!stew From: stew@harvard.ARPA (Stew Rubenstein) Newsgroups: net.lang.c Subject: Re: ANSI C: CPP predefined constants vs.Message-ID: <103@harvard.ARPA> Date: Sun, 21-Oct-84 04:03:33 EDT Article-I.D.: harvard.103 Posted: Sun Oct 21 04:03:33 1984 Date-Received: Mon, 22-Oct-84 02:38:42 EDT References: <420@diku.UUCP> Organization: Aiken Computation Laboratory, Harvard Lines: 52 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@harvard