gwyn@smoke.BRL.MIL (Doug Gwyn) (04/21/89)
In article <1954@trantor.harris-atd.com> bbadger@x102c.harris-atd.com (Bernie Badger Jr.) writes: >Is there a way to find out what macros are defined? It's particularly hard >to predict which names will be _predefined_. ... This is not an issue for Standard C, since the only predefined macros allowed are those specified in the Standard and optionally additional implementation-specific ones that must have names starting with _. If you do not use _-names in your application code, it will be impervious to predefined vendor macros in any Standard conforming implementation; thus why would you care what they were? The particular set of predefined vendor macros may very well depend on the options supplied to the compiler when it is invoked.
meissner@tiktok.dg.com (Michael Meissner) (04/27/89)
In article <1954@trantor.harris-atd.com> bbadger@x102c.harris-atd.com (Bernie Badger Jr.) writes: /* ... */ | What I want is a way to find out *all* the names that are defined. | | I don't believe that the current cpp implementations have a way to do this, | so I am really proposing defining a ``standard option'' which could be | implemented in future cpp's. Actually the cpp that comes with GNU 1.34 has a switch to do what you want, though it is undocumented. If you invoke /usr/local/lib/gcc-cpp with the -d switch, it will do the preprocessing, but only emit the #defines (including the default definitions). Thus, you wound say: /usr/local/lib/gcc-cpp -d </dev/null to get the names that are defined. Also note that both the Sun /bin/cc and GNU GCC have a switch: -v which prints a verbose trace of each program executed, and the switches passed to it. Both of these compilers pass -undef to the preprocessor, which means ignore the default defines, only use the defines as defined with -D on the cpp command line. The -v switch also prints all of these names. I've redirected followups to comp.lang.c, which seems a more appropriate newsgroup than either comp.unix.questions, or comp.std.c. -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner If compiles were much Internet: meissner@dg-rtp.DG.COM faster, when would we Old Internet: meissner%dg-rtp.DG.COM@relay.cs.net have time for netnews?
curtw@hpcllca.HP.COM (Curt Wohlgemuth) (04/29/89)
> Is there a way to find out what macros are defined? It's particularly hard > to predict which names will be _predefined_. You may want to try this script. I got the basic sed part from a friend who got it off of some notes group or other. I changed it because we have a cpp which does not act as a filter; it needs an input file. Here it is: ------------------------------------------------------------- #! /bin/ksh SELF=`basename $0` PATH=:/bin:/usr/bin:/usr/local/bin TEMP=/tmp/t$$ OUTFILE=/tmp/out$$ trap "rm -f $TEMP $OUTFILE" 0 1 2 if [ $# -lt 1 ]; then echo "usage: $SELF <cpp> [ options ]" exit 1 fi CPP=$1 shift OPTIONS="$*" strings -a -2 $CPP | sed '/^a-zA-Z0-9_/!s/.*/#ifdef &\ "%&"\ #endif/p' > $TEMP $CPP $OPTIONS $TEMP > $OUTFILE 2> /dev/null sed -n '/%/s/[%"]//gp' $OUTFILE | sort | uniq rm -f $TEMP $OUTFILE exit 0
abcscnge@csuna.csun.edu (Scott "The Pseudo-Hacker" Neugroschl) (04/30/89)
In article <1954@trantor.harris-atd.com> bbadger@x102c.harris-atd.com (Bernie Badger Jr.) writes: >Is there a way to find out what macros are defined? It's particularly hard >to predict which names will be _predefined_. I am also interested in finding out about what are the "manifest defines" of a CC implementation. I write code for 5 different platforms, and would like it to be semi-portable (e.g. #if vax || M_8086 read(fd,&data,nbytes); swab(&data,&data,nbytes); /* swap for byte swapped machine */ #endif System Manifest Defines ------------------ --------------------- SCO Xenix SysV/286 (M_8086 or some such) AT&T 3B15 (don't know) VAX/Ultrix (vax) Motorola System V/68 (m68k????) ZEUS (Zilog Unix Sys III) (z8000) Each of these has their own manifest defines, but they are not well documented (if at all). IMHO, the man page for cc(1) or cpp(1) should specify what that particular preprocessor implementation pre-defines. I like the suggestion for #dump "file". Did anyone suggest this to the X3J11 committee? -- Scott "The Pseudo-Hacker" Neugroschl UUCP: ...!sm.unisys.com!csun!csuna.csun.edu!abcscnge -- unless explicitly stated above, this article not for use by rec.humor.funny -- Disclaimers? We don't need no stinking disclaimers!!!
bph@buengc.BU.EDU (Blair P. Houghton) (04/30/89)
In article <1938@csuna.csun.edu> abcscnge@csuna.csun.edu (Scott Neugroschl) writes: >In article <1954@trantor.harris-atd.com> bbadger@x102c.harris-atd.com (Bernie Badger Jr.) writes: >>Is there a way to find out what macros are defined? It's particularly hard >>to predict which names will be _predefined_. > >I am also interested in finding out about what are the "manifest defines" of >a CC implementation. I write code for 5 different platforms, and would >like it to be semi-portable (e.g. > >#if vax || M_8086 > read(fd,&data,nbytes); > swab(&data,&data,nbytes); /* swap for byte swapped machine */ >#endif > > System Manifest Defines > ------------------ --------------------- > SCO Xenix SysV/286 (M_8086 or some such) > AT&T 3B15 (don't know) > VAX/Ultrix (vax) > Motorola System V/68 (m68k????) > ZEUS (Zilog Unix Sys III) (z8000) > >Each of these has their own manifest defines, but they are not well >documented (if at all). IMHO, the man page for cc(1) or cpp(1) should >specify what that particular preprocessor implementation pre-defines. >I like the suggestion for #dump "file". Did anyone suggest this to >the X3J11 committee? I think I understand, but if I don't, it will be obvious, but it's no less instructive, what I have to say, so... I once wanted to know which set of numbers I would be getting from #include <values.h> on a certain machine. (The Encore Multimax, for which your table's entry, for this particular machine, would go Multimax/Umax (ns32000) .) So, while the sysadmin was looking it up, I decided just to monkey with all the #ifdef's in values.h to see which ones came up. I just took out all the #define statements and replaced them with `printf ("ns32000 || vax");' and the like, depending on what the in-scope #ifdef's were using. To be certain, I threw in an #else for each #ifdef (if it wasn't already there) to say `printf("NOT blivit || foobus || vax");' or whatever needed to be said. So, it seems, if necessary you can always go looking into values.h to see which 'manifest defines' your implementation is using. The least you can get is a list of the ones it _could_ be using, and cobble up a string of #ifdef/printf/#endif chunks to find out for sure. --Blair "Predicated on the portability of values.h, of course..."
dave@lethe.UUCP (Dave Collier-Brown) (05/03/89)
In article <1954@trantor.harris-atd.com> bbadger@x102c.harris-atd.com (Bernie Badger Jr.) writes: >Is there a way to find out what macros are defined? It's particularly hard | to predict which names will be _predefined_. In article <1938@csuna.csun.edu> abcscnge@csuna.csun.edu (Scott Neugroschl) writes: | I am also interested in finding out about what are the "manifest defines" of | a CC implementation. I write code for 5 different platforms, and would | like it to be semi-portable ... Well, its formally impossible to predict what names will (eventually) be predefined. So I recommend approaching the problem from a different direction. What you want to know is whether or not a certain capability is present, and if so how to access it. Saying "#ifdef 4.2BSD" is far too coarse for most typical problems. So I depend on a bug (!). C compilers used to depend on sequences of #ifdefs to ensure that the contents of system .h files were not inadvertently redefined by including the containing files more than once. Even ANSI C requires this to protect typedefs (the macro bug got fixed: see aother discussuion in this same forum). So when I'm about to call something whose interface might change (or be absent!), I grep the man page for #include strings and pop up the relevant .h file in another window/another editor. This usually contains something like #ifndef _BSD_PECULIAR_SHMOPS #define _BSD_PECULIAR_SHMOPS typedef struct shmop_t { ... } SHMOP; SHMOP *shmooze(struct time_t howlong); ... so I can can just copy the definition of shmooze() into the code I'm writing, along with the #ifndef, which gets its "n" deleted. And away we go. Of course, half the time I have to AMEND the #include files, but thats' another story... (:-{). -dave -- David Collier-Brown, | {toronto area...}lethe!dave 72 Abitibi Ave., | Joyce C-B: Willowdale, Ontario, | He's so smart he's dumb. CANADA. 223-8968 |
ian@sq.com (Ian F. Darwin) (05/04/89)
> > Is there a way to find out what macros are defined? It's particularly hard > > to predict which names will be _predefined_. > > You may want to try this script. I got the basic sed part from a friend > who got it off of some notes group or other. I changed it because we > have a cpp which does not act as a filter; it needs an input file. The script posted is a valiant attempt, but it's doomed to failure because it contains some unstated and unfortunate assumptions about the private internal data structure of C preprocessors. (I'm ignoring the fact that it uses "strings", which is only standard in BSD systems; it is at least possible to write a "strings" command for any given a.out format, and there are versions kicking around for COFF and some other formats). You cannot validly make the assumption that all C preprocessors will store each predefined string as a separate "strings"-able entity. One cpp might predefine them all as one giant string; another might encode them somehow; another might have them in the "cc" command rather than in cpp. The SVID and probably other standards have long advocated that "the recommended way to invoke cpp is through the cc command"; pANS doesn't even require that cpp be implemented as a separate program. For a chuckle, try running it on gcc's cpp. The posted version of the script first fails because it sets the path to exclude /usr/ucb, where "strings" is on our system. When you fix this, it gets a syntax error (at least on this system, a Sun 3 running SunOS 3.x). To answer the original question, "to find out what macros are defined", read the compiler's documentation. If the predefined macros aren't documented, complain to your vendor. If that doesn't help, buy from a different vendor next time, and let the losers (and maybe the appropriate newsgroups/mailing lists) know why. Ian F. Darwin, SoftQuad Inc., Toronto, utzoo!sq!ian, ian@sq.com
karl@haddock.ima.isc.com (Karl Heuer) (05/04/89)
In article <1938@csuna.csun.edu> abcscnge@csuna.csun.edu (Scott Neugroschl) writes: >I am also interested in finding out about what are the "manifest defines" ... >I like the suggestion for #dump "file". Did anyone suggest this to the X3J11 >committee? If so, the Committee was right to reject it. This is essentially a compiler debug flag, which has no business being embedded in the language. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (05/05/89)
In article <1954@trantor.harris-atd.com> bbadger@x102c.harris-atd.com (Bernie Badger Jr.) writes: >Is there a way to find out what macros are defined? It's particularly hard >to predict which names will be _predefined_. ... 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? -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/05/89)
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.
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (05/06/89)
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. It is a terrible idea to make any assumptions about vendor-specific symbols. There are two reasons for this. 1. You code should not be dependent on vendor-specific or OS-specific symbols. It ought to be dependent on specific attributes of different environments. For example: #ifdef unix ... code that assumes UNIX-like hard links ... /* BAD */ #endif #ifdef NIX_LINKS ... code that assumes UNIX-like hard links ... /* BETTER */ #endif This way if you encounter a new system with some specific attributes, you do not have to go searching through your code to figure out what to change. 2. Do not trust vendor-supplied symbols. They are often wrong. I found out from Usenet that some Sun machines define "vax". Worse, System V machines define "unix". The right way to deal with predefined symbols is to put all dependencies on them in a separate header file, and *manually edit that file* when installing software on a new system. -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
jagardner@watmath.waterloo.edu (Jim Gardner) (05/06/89)
In article <10214@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >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. [...] > >Not in that form, that I recall, but there were a variety of suggestions >for ways to "standardize" such parameterization of the environment. > [...] 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. <default.h> (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. David Tanguay
scott@dtscp1.UUCP (Scott Barman) (05/07/89)
In article <7119@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >2. Do not trust vendor-supplied symbols. They are often wrong. I >found out from Usenet that some Sun machines define "vax". Worse, >System V machines define "unix". Not that I am any lover of System V but: Isn't System V Unix? I'm not trying to start a religous argument (lord knows I did this once and 10K of flaming email puts a damper on a day :-), but forgetting you feelings twoards System V, I would think it would be OK for "unix" to be defined. Besides, I think our AT&T source license call is The Unix Timesharing System V. -- scott barman {gatech, emory}!dtscp1!scott
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/08/89)
In article <675@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: > Isn't System V Unix? Is a bear Catholic?
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (05/08/89)
In article <1339@ncr-sd.SanDiego.NCR.COM> I write: >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. In article <7119@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >It is a terrible idea to make any assumptions about vendor-specific symbols. >There are two reasons for this. I completely concur -- but this wasn't my point. What I'm considering is the mechanism, not the contents. Once the mechanism is determined, we can moot the contents, but as long as the mechanism is outside the control of the system administrator, we are pretty much stuck with the ad-hoc stuff we have now. I think that if the mechanism were not wired in, there would be some pressure for standard things to be expected in <default.h>, the same way there is pressure for standard things in, say, <values.h>. And it would provide a home for the #define that specified POSIX conformance (or whatever). >Worse, System V machines define "unix". Er, this seems reasonable to me -- I thought it was.... >The right way to deal with predefined symbols is to put all >dependencies on them in a separate header file, and *manually edit that >file* when installing software on a new system. Your point is taken, although I prefer a Configure script or other mechanism to build the information, as there's less chance for error. -- -- Greg Noel, NCR Rancho Bernardo Greg.Noel@SanDiego.NCR.COM or greg@ncr-sd
greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) (05/08/89)
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. ><default.h> (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 <default.h> 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
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (05/08/89)
In article <675@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: > Isn't System V Unix? The term Unix has two different meanings. One, the generic meaning, derives from common usage. Unix here is a noun that stands for a family of operating systems. Both Version 7 and BSD are Unix. This meaning of Unix was established long before System V existed. The other, the legal meaning, derives from trade-mark law. Were AT&T to enter the shoe business, it could without any deception sell you UNIX shoes. Here UNIX is merely used for name recognition and has no meaning of its own. AT&T lawyers will rush to tell you that there is no such thing as UNIX, since UNIX (the trade-mark) is an adjective and not a noun. While System V is sold under the UNIX label, System V itself (a noun) is not UNIX (an adjective as used here). (Followups to comp.unix.questions, please.) -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
seanf@sco.COM (Sean Fagan) (05/09/89)
In article <7130@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >In article <675@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: >> Isn't System V Unix? >The term Unix has two different meanings. >One, the generic meaning, derives from common usage. Unix here is a >noun that stands for a family of operating systems. Both Version 7 and >BSD are Unix. This meaning of Unix was established long before System >V existed. >While System V is sold under the UNIX label, System V >itself (a noun) is not UNIX (an adjective as used here). Gee, that's funny. I learned Unix on an AT&T machine (a 3b5), pure vanilla AT&T System V Release 2.1.0 UNIX(tm). A year or so later, I got an account on this wierd system, called (I think) BSD, or some such. SysV is as much unix (or more so) as bsd. Actually, since SysV is larger, I guess you could say it's *more* unix than bsd. Oh, and btw: unix is not a common noun. Although I miscapitalize it, unix is, has been, and, probably, always will be, associated with the AT&T operating system, trademarked under the name UNIX. -- Sean Eric Fagan | "An acid is like a woman: a good one will eat seanf@sco.UUCP | through your pants." -- Mel Gibson, Saturday Night Live (408) 458-1422 | Any opinions expressed are my own, not my employers'.
ed@mtxinu.COM (Ed Gould) (05/09/89)
Greg Noel: >>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. Doug Gwyn: >[It was not suggested] 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. I think Doug missed the point of the question. Remember that the original discussion was about how to determine what names are defined in the local environment. The question is not what to define, but where to define it. As I understand the suggestion, the <default.h> file would contain all of the names defined in the local environment that weren't absolutely required by the standard. Thus, for example on a Vax Unix system (using pre-ANS names), it might contain, among other things, #define unix 1 #define vax 1 (By "absolutely required" I mean those names that are specifically required and that the name and value of which are stated in the standard. There may be none other than _STDC_ [or however that one is spelled]). By examining <default.h> the user could determine exactly what would be predefined. It might be that there would need to be special handling of this file, so that -U would be meaningful: <default.h> might need to be read before parsing command-line arguments. But that's no different than having the symbols hard-coded into the compiler (or pre-processor, in this case). -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA ed@mtxinu.COM +1 415 644 0146 "I'll fight them as a woman, not a lady. I'll fight them as an engineer."
henry@utzoo.uucp (Henry Spencer) (05/09/89)
In article <1348@ncr-sd.SanDiego.NCR.COM> Greg.Noel@SanDiego.NCR.COM (Greg Noel) writes: >>The right way to deal with predefined symbols is to put all >>dependencies on them in a separate header file, and *manually edit that >>file* when installing software on a new system. > >Your point is taken, although I prefer a Configure script or other mechanism >to build the information, as there's less chance for error. The problem with Configure scripts and the like is that unless they are *very* very cleverly done -- I haven't seen any yet that would qualify, I'm afraid -- they usually end up making invalid simplifying assumptions. For example, that the world is divided into System V and BSD systems, when in fact more and more systems are hybrids. They do this because some of the things they want to know are hard to figure out directly, and hence they try to infer them from questions like "which flavor of Unix do you have?"... and often get them wrong. Hand editing is the only real solution at present. -- Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology 2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
flee@shire.cs.psu.edu (Felix Lee) (05/09/89)
Here's an extraordinarily silly idea for <default.h>. Since the list of predefined symbols can vary due to environment and compilation flags such as -U, <default.h> should look something like #ifdef unix #define unix 1 #endif except that this would break with "-Uunix -Dunix=bsd", so you have #ifdef unix /* #define unix 1 */ #endif I'd complain if the compiler documentation didn't list predefined symbols or tell you a method of finding predefined symbols. Now, being able to say something like #pragma dumpdefines at an arbitrary point would be interesting. -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!shire!flee
gordon@sneaky.UUCP (Gordon Burditt) (05/10/89)
>I think Doug missed the point of the question. Remember that the >original discussion was about how to determine what names are defined >in the local environment. The question is not what to define, but "what names are defined in the local environment" is ill-defined. Do you mean (and I am making unwarranted assumptions about how compilers are invoked, but assuming "traditional UNIX compiler flags"): a) The list of all preprocessor symbols that might be predefined under appropriate circumstances, excluding the effect of -D and -U flags? b) The list of all preprocessor symbols that are predefined on THIS compilation, excluding the effect of -D and -U flags (which is obviously undefined if there is no compilation in progress)? c) The list of all preprocessor symbols that will always be predefined on ANY compilation for this compiler, excluding the effect of -D and -U flags? It seems to me that what is wanted is list (a) in the compiler documentation, along with explanations of the conditions that apply to symbols on list (a) but not list (c). I certainly don't want <default.h> to be modified often ("Could you put up the default.h for nethack, please?"; "NO! I'm in the middle of compiling something else!") >where to define it. As I understand the suggestion, the <default.h> >file would contain all of the names defined in the local environment >that weren't absolutely required by the standard. Thus, for example on >a Vax Unix system (using pre-ANS names), it might contain, among other >things, > #define unix 1 > #define vax 1 >By examining <default.h> the user could determine exactly what would be >predefined. It might be that there would need to be special handling If all you want to do is READ it, it would seem sufficient to put it in the compiler (printed) documentation. And in that case, there would be no need for the compiler to read it if it were already compiled in. >of this file, so that -U would be meaningful: <default.h> might need >to be read before parsing command-line arguments. But that's no >different than having the symbols hard-coded into the compiler (or >pre-processor, in this case). Many compilers predefine symbols conditionally depending on a combination of various compiled-in defaults and compiler flags (No, I don't mean -D and -U). Yes, I really mean that some symbol is defined or not depending on whether the compiler is told to use 286 instructions on the command line, or whether the 'char' type is to default signed or unsigned (again, changable from the command line). Usually this is implemented by having the front-end program pass -D flags to the preprocessor depending on what other flags it got. Defines based on: Who does it: "char" type unsigned GNU C Memory model Microsoft C 5.1 (MS-DOS), Xenix/*86 CPU type within family GNU C, Microsoft C 5.1 (MS-DOS), Xenix/*86 Floating point unit type GNU C, ?? Sun ?? OS version/object format Xenix/68000 System III ANSI compatable compilation GNU C Compilers that do conditional predefinition: GNU C (all versions, I think, although the degree varies) Microsoft C 5.1 (MS-DOS) Xenix/*86 (all versions, I think) Xenix/68000 System III Compilers that don't do conditional predefinition: Vax 4.3bsd Another thing to think about is the wierd interaction that would happen between the -I flag and the default.h file, especially if the specified directory has a default.h in it. I can think of examples (cross-compilers) where this would be mostly beneficial, and others where it would confuse things considerably. _____________________________ /* default.h */ /* note wierd pragmas required to implement default.h */ # define unix 1 # define M_XENIX 1 # pragma if $cmdarg("-v") != "3" && $cmdarg("-v") != "" # pragma if $compiled_default("strict_ansi") || $cmdarg("-pedantic") # define __M_V7__ 1 # pragma else # define M_V7 1 # pragma endif # pragma else # pragma if $compiled_default("strict_ansi") || $cmdarg("-pedantic") # define __M_SYS3__ 1 # define __M_SYSIII__ 1 # pragma else # define M_SYS3 1 # define M_SYSIII 1 # pragma endif # pragma endif /* GNU C defines this as the base file (the value of __FILE__ as it would */ /* be on the first line of source read) What value do I use for this */ /* in a file? */ # define __BASE_FILE__ "God only knows what goes here" # pragma if $cmdarggiven("-m68881") # define __M68881__ 1 # pragma endif # pragma if $compiled_default("unsigned_char") || $cmdarggiven("-funsigned-char") # define __CHAR_UNSIGNED__ 1 # pragma endif Gordon L. Burditt ...!texbell!sneaky!gordon