Xref: utzoo comp.unix.questions:13344 comp.std.c:1164 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!helios.ee.lbl.gov!nosc!ncr-sd!greg From: greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) Newsgroups: comp.unix.questions,comp.std.c Subject: Re: How can I find out cc or cpp symbols? Keywords: cpp, cc, macros Message-ID: <1350@ncr-sd.SanDiego.NCR.COM> Date: 7 May 89 23:44:51 GMT References: <1339@ncr-sd.SanDiego.NCR.COM> <10214@smoke.BRL.MIL> <25890@watmath.waterloo.edu> Reply-To: Greg.Noel@SanDiego.NCR.COM (Greg Noel) Organization: NCR Corporation, Rancho Bernardo Lines: 24 In article <25890@watmath.waterloo.edu> jagardner@watmath.waterloo.edu (Jim Gardner) writes: >Also, I don't recall that ANSI has specified that the standard headers even >have to be files: they could be built in to the compiler. Even if they are >files, they don't have to be text files that you can easily replace. This is a point, but I'd consider it unlikely. Since the ability to read user-provided #include files needs to be present, it would be extra effort to provide a different way to handle standard #includes. And even if the compiler did something like this, say like the pre-compiled headers provided in the Manx C compiler on the Amiga, I'd be surprised if the originals weren't provided as well. > (in effect) could be something that is built by the compiler >at compile time, defining things differently depending on how the compiler >was invoked, and maybe on things that it can determine about its environment. This is a more interesting point, and one I hadn't considered. Ideally, there would be some way to specify dynamically-determined things directly in the #include file, but I have no idea how this might be done. Perhaps could be considered the, ah, default set of options that could be over-ridden by command-line flags? But then we're back to where we started.... Hmmmm... -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd