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

[Keld J|rn Simonsen]

<>

One thing I would like from the C standard, is that
as much software as possible could compile *unmodified* on different 
processor types, under different families of operating 
systems, and under different levels of an operating system.
This should be done by #ifdef-ing or testing on some well
defined constants, which should be agreed upon (obviously!).

Lately there has been some discussion on C preprocessor defined
constants. Well this is good for thing as __LINE__ numbers and
__DATE__ compiled, but for operating systems levels, processor type, 
machine brand etc. I think it is a very bad idea.
I advocated a while ago on the net for use of the <whoami.h> include 
file as a solution to some problems. I will elaborate a little more 
on this seen from an ANSI C standard point of view.

I think it is a bad idea to have this information build in the C
compiler. C is not the only systems language around in the Unix
world, we also have Pascal and Modula-2. The ANSI C is not intended
for use with the Unix system only, there are C compilers for
CP/M, MS-DOS, OS/370, VMS etc, and all these systems surely have
other systems programming languages interested in knowing
OS level, processor type etc. This information should be 
stored in a *unique* place retrievable from all languages/
software interested, and all important site dependent information
should also be collected here, so you only have one place to go
when the ordinary system adminstrator installs his/her *binary*
system. 

I think the way to configure in this one unique place should provide
both for binary only and source systems. This boils down to 
#ifdef vs. getfoobar(3) techniques, and I think there is a place for 
obtaining information in both ways for the same item. E.g. nowadays
we compile conditionally on the OS level V7/BSD/S5. Someday we may
have a common object format and file system format constant over 
several levels of the OS, so the same application program could
run with only minor actions to OS level differencies under these OSes.
We also may have machines running several different flavors of an OS
(e.g. 4.2BSD and System V) at the same time with only minor differences.
A source system would be happy with some C preprocessor syntax like 
#define statements, and that could go for several other systems 
programming languages. The binary system would go for some termcap(5)
like information base, it could perfectly be in *C header* syntax.
We then just have to write info routines, e.g. defines(3) -
get string value - and definen(3) - get num value - 
netnews is already distributed with such routines, and they are simple!
We then would have one *unique* place to configure and seek for system
dependent information for both source and binary systems.

Using <whoami.h>  is simple (Unix style, folks!). Every system
manager can edit this include file; it is not so easy to 
get information out of a binary file (like the kernel), or even change 
or add items in it. <whoami.h> can exist easily on even V6, PWB and S5,
and can easily be updated to include items like organization
name needed for netnews, but not provided by any existing 
Unix OS in system calls. So we could eliminate ifdef-ed calls to
gethostname(2), uname(2) and what they call it on IBM, Sperry (MSCON$)
etc. I.e. simpler programs! Adding a <whoami.h> file on an existing 
system is simple, so *existing* C compilers could easily be made to 
comform to the standard on this point, also on UNIX systems already 
in service.

The problem of predefined constants unknown to a programmer is
also quite simple to solve, you just don't #include <whoami.h>!
So don't do it in CPP, use <whoami.h> instead!

Keld Simonsen, DIKU, U of Copenhagen         ...decvax!mcvax!diku!keld