Xref: utzoo comp.unix.questions:13282 comp.std.c:1153
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.questions,comp.std.c
Subject: Re: How can I find out cc or cpp symbols?
Keywords: cpp, cc, macros
Message-ID: <10214@smoke.BRL.MIL>
Date: 5 May 89 16:23:31 GMT
References: <1954@trantor.harris-atd.com> <10084@smoke.BRL.MIL> <1339@ncr-sd.SanDiego.NCR.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 17

In article <1339@ncr-sd.SanDiego.NCR.COM> Greg.Noel@SanDiego.NCR.COM (Greg Noel) writes:
>I've wondered why the ANSI committee didn't simply mandate that there be a
>header file, say <default.h>, that was implicitly #included, and that contained
>all the machine-specific, system-specific, and vendor-specific names.  This
>would give you the option to look at them, provide a replacement (useful for
>cross-compilations), or generally do anything you wanted with them.  Doug,
>was this ever suggested?

Not in that form, that I recall, but there were a variety of suggestions
for ways to "standardize" such parameterization of the environment.
Basically the use of macros for denoting specific operating systems and
hardware doesn't seem to be fine-grained enough.  People who specialize
in portable applications usually have their own methods for dealing with
such environmental variation, and it doesn't seem that one particular
method stands out as one that should be "legislated".  The emphasis was
on providing a sufficiently useful standard environment that there would
be little need for conditionalizing code based on such factors.