Standard pre-defined CPP symbols

[Kevin Martin]

>From marcus at pyuxt.UUCP (M. G. Hand) Thu Jul  5 17:50:02 1984
>I encountered the following problem a couple of weeks ago:
>	Between USG 5.2 and 5.3 (sic) - these are S5 releases for the 3B5 -
>	the defined constant _u3b disappeared from the system with the
>	consequence that one of my programs stopped compiling.  Now I have
>	to:
>	#if	defined(_3b) || defined(_3b5)
>What this does is to underline the need for a series of standard names which
>covers Unix versions and the hardware on which it runs; and, when I say
>*standard* I mean well known, well documented, and universally adhered-to.

Also, hopefully, following some naming convention, so a programmer
can feel safe that his variable names will never be eaten by some CPP of
the future.

Although not particularly useful in most cases, cross-compiled code should
have the ability to determine both the target machine (and os version) *and*
the host machine and os. The former is the most commonly used (and appears
to be the equivalent to the current symbols such as 'unix'). The latter is
used e.g. when a #include statement might have to look different (on non-
unix systems).
Our locally-written C compiler pre-defines names of the form TM_xxx, TS_xxx,
HM_xxx, and HS_xxx, representing respectively the target machine, target
system, host machine and host system. The target system is also used to
determine the name of the system include file directory. We are considering
making lint be its own target system & target machine, which appears to have
several advantages.
The names are kind of ugly, but then, no one is likely to name a variable
TM_DPS6. There are naming problems (e.g. is that Honeywell machine
referred to as TM_6600, TM_L66, or TM_DPS8 ? answer: Deepends which
year you bought it...), and there is sometimes confusion over which
manifest to use (in particular, HS_ and HM_ are often confused).