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.
rbj@dsys.icst.nbs.gov (Root Boy Jim) (04/22/89)
? Is there a way to find out what macros are defined? It's particularly hard
? to predict which names will be _predefined_.
? What I want is a way to find out *all* the names that are defined.
You can do this by a somewhat roundabout route. First you run the command
`strings' (if you have it) on the cpp binary. You then grep out only the
legal preprocessor strings (only alphanumeric or underscores not starting
with a digit). Then pipe it to an awk command which turns `foo' into
#ifdef foo
printf("foo\n");
#endif
and brackets the whole thing with "main () {" and "}". Sen the output
to a file, compile it, link it, and run it. Voila!
? 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.
? My proposals are:
? 1) #dump [rest of proposals deleted]
I would suggest a command line option rather than input source.
? Q1: Has anyone else wanted this capacity?
Obviously, since I didn't make it up. I forget where I saw it.
? Q2: Has anyone used a system with this capacity?
? Q3: What other uses can you think of for this capacity? (Besides verifying
? the honesty of the documentation?)
Larry Wall has a script called "Configure", which he distributes with
"patch" (and probably everything else he writes). Its purpose is to
determine what kind of system you are running on and set up flags
correctly for his makefiles and program source.
His approach is to catalogue all possible variants that might affect
automation of program compilation/installation and minimal tailoring.
Thus, he keeps a static list of preprocessor symbols that *he* cares
about, and challenges anyone to break (and then fix) his script.
? Q4: Are there similar problems in other tools?
Undoubtedly.
? I'm mostly thinking of interactive tools:
? o editors
? - vi has ":set all",
? - GNUemacs has a slew of "apropos" and "describe" features
? o debuggers
? - dbx (some versions) has variable and command expansion
? - sdb has variable matching, but I'm not sure it will list them for you
? o shells
? - sh and ksh have printenv
? - csh has set, alias and printenv commands.
? but they won't describe their own command syntax.
Try the `man' command :-)
? o databases
? - catalogs and views of the tables and views.
? Bernard A. Badger Jr. 407/984-6385 |``Use the Source, Luke!''
? Secure Computer Products |``Get a LIFE!'' -- J.H. Conway
? Harris GISD, Melbourne, FL 32902 |Buddy, can you paradigm?
? Internet: bbadger%x102c@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively
Root Boy Jim is what I am
Are you what you are or what?merlyn@intelob.intel.com (Randal L. Schwartz @ Stonehenge) (04/24/89)
In article <19236@adm.BRL.MIL>, rbj@dsys (Root Boy Jim) writes: | You can do this by a somewhat roundabout route. First you run the command | `strings' (if you have it) on the cpp binary. You then grep out only the | legal preprocessor strings (only alphanumeric or underscores not starting | with a digit). Then pipe it to an awk command which turns `foo' into | | #ifdef foo | printf("foo\n"); | #endif | | and brackets the whole thing with "main () {" and "}". Sen the output | to a file, compile it, link it, and run it. Voila! Here's what I have... I call it 'whatdef': strings -2 /lib/cpp | grep '^[_A-Za-z][_A-Za-z0-9]*$' | sort -u | awk ' { print "#ifdef " $0 print "__" $0 "__ is defined" print "#endif" } ' | /lib/cpp | sed -n 's/^__\(.*\)__ is defined$/\1/p' I probably could have done the middle in sed, but I didn't feel like hacking the backslashes and newlines. Note the new address in the .sig.... -- /=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095===\ { on contract to BiiN, Hillsboro, Oregon, USA, until 01 June 1989 } { <merlyn@intelob.intel.com> ...!uunet!tektronix!biin!merlyn } { or try <merlyn@agora.hf.intel.com> after 01 June 1989 } \=Cute quote: "Welcome to Oregon... home of the California Raisins!"=/
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?
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 |
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
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