kpmartin@watmath.UUCP (Kevin Martin) (07/06/84)
>From marcus@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).