Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!rutgers!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: ANSI C -- site identification Message-ID: <5459@brl-smoke.ARPA> Date: Mon, 15-Dec-86 14:47:46 EST Article-I.D.: brl-smok.5459 Posted: Mon Dec 15 14:47:46 1986 Date-Received: Wed, 17-Dec-86 18:53:46 EST References: <110@decvax.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 26 In article <110@decvax.UUCP> minow@decvax.UUCP (Martin Minow) writes: >Page 82, line 34. Many, if not all, existing implementations pre-define >implementation-specific preprocessing variables that specify the processor, >operating system, and, in some cases, the compiler name. For example, Decus >C predefines ``pdp11'', ``decusc'', and either ``rt11'' or ``rsx.'' For >better or for worse, this tradition is almost ten years old. Some provision >should be made for this in Standard C. I missed the discussion on this, so I can't tell you why it's specified the way it is, other than perhaps to avoid unpleasant surprises such as: int sun; /* struct or union flag */ int sel; /* selection value */ both of which get mangled by pre-#defines that I'm aware of. There has been a suggestion made that such pre-defined names could be handled in a special way, to avoid this kind of problem, but so far I haven't seen a really appealing proposal for this. > __PROCESSOR__ defines the processor that the compiler is > targetted for. The problem with such things is that they are only useful if there is standardization of the "official" formats and lists of possible values. It is definitely outside the scope of X3J11 to set up such schemes.