wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (08/21/90)
In article <185@n4hgf.Mt-Park.GA.US> I wrote: > I would like to compile a list of pre-defined manifest constants > supplied by various C compilers. I apologize for the lousiness of this summary. I meant to make a tabular representation, but my typing is already slow and I have been quite ill since posting the request. I will attempt to do so when I get well. Thanks to each of you for your response. ---------------------------------------------------------------------------- Pat Rankin, rankin@eql.caltech.edu DEC's C compiler for VMS defines the following: VAX, vax /* hardware */ VMS, vms /* operating system */ VAXC, vaxc /* compiler name (current) */ VAX11C, vax11c /* obsolete compiler name */ Two other tokens (set to 1 or 0, not defined vs undefined) are set up based on command line switches: CC$gfloat and CC$parallel. GCC (GNU C) defines 'vax' (but not 'VAX'), both 'vms' and 'VMS', and also '__GNUC__' and '__STDC__'. Due to inadequate documentation, I'm not sure if it has any others. Note that ANSI mandates that things of this nature must begin with two underscores. It will be interesting to see how the various compilers make the conversion. DEC stresses backwards compatability (meaning don't make changes which break existing code) very strongly; eliminating pre-defined 'VMS' and 'vms' will break lots of stuff. Their C implementation is not as successful at retaining compatability as most of their other software, but I suspect they'll add a command line switch (possibly turned on by default) which specifies whether to define these non-ANSI tokens. Pat Rankin, rankin@eql.caltech.edu ---------------------------------------------------------------------------- charlie@stat.washington.edu (Charlie Geyer) The IBM PC/RT defines ibm032 what 032 is, I don't know. I know you probably don't care, and RTs are almost defunct anyway, but maybe you can use it as a trivia question someday. Anyway, you did ask. ---------------------------------------------------------------------------- Alex Pruss pruss@ria.ccs.uwo.ca Under MSDOS: MSDOS -- defined by Microsoft C __MSDOS__ -- defined by Turbo C __TURBOC__ -- Turbo C version number 0x0150 is 1.50, etc. then of course there is __GNUC__ for gcc, and __STDC__ for ANSI. ---------------------------------------------------------------------------- John Limpert johnl@gronk.UUCP This system (UniPlus 5.0 on a Heurikon HK68) defines 'mc68000' and 'unix'. ---------------------------------------------------------------------------- lerman@stepstone.com (Ken Lerman) HP800: D__STDC__ -D__hp9000s800 -D__hppa -D__hpux -D__unix DG Aviion: D__ghs__ -D__m88k__ -D__DGUX__ -D__STDC__ -D__unix__ -D__using_DGUX DEC3100: -Dmips -DLANGUAGE_C -DMIPSEL SCO unix: -DM_I86 -DM_I86SM -DM_SDATA -DM_STEXT -DM_I386 -DM_XENIX -DM_BITFIELDS -Di386=1 -DM_INTERNAT -Dunix=1 -DM_UNIX -DM_COFF -DM_SYS5 -DM_SYSV -DM_SYS3 -DM_SYSIII -DM_WORDSWAP -D__STDC__=0 The above are the switches we set when using our own preprocessor on the above platforms. Unfortunately, the list may not be complete or up to date. What I generally do with a new platform is first grep the files in /usr/include and its subdirectories looking for #ifdefs or #if defined. I then make a test program that looks like: main() { #if defined(A_CANDIDATE_MANIFEST_CONSTANT) printf("A_CANDIDATE_MANIFEST_CONSTANT = %d\n", A_CANDIDATE_MANIFEST_CONSTANT); #endif } So far, I haven't been bitten by the fact that the constant may not be an integer. Of course, I could just look at the preprocessor output for the above program (assuming the system has that facility). ANSI could have done us all (well, those of us who care) a big favor by requiring conforming compilers to either have a switch which causes the display of all of the predefined manifest constants or a document describing such constants. ---------------------------------------------------------------------------- Larry Jones scjones@thor.UUCP According to my System V manual, you should add the following: operating system: unix, dmert, gcos, ibm, os, tss hardware: i286, interdata, u370, u3b, u3b5, u3b2, u3b15, u3b20d UNIX system variant: RES, RT lint: lint DEC's Vax-11 C for VMS (and, I presume, Ultrix) defines: operating system: vms, VMS hardware: vax, VAX compiler: vaxc, VAXC, vax11c, VAX11C SAS's compiler for the IBM 370 defines: operating system: OSVS, CMS compiler: I370 debugging: DEBUG, NDEBUG ---------------------------------------------------------------------------- donp@novell.com (don provan) A noble goal. In Microsoft C 5.1 i find an OS specified: MSDOS; some additional "machine types" (really memory model indications): M_I86SM, M_I86CM, M_I86MM, M_I86LM, M_I86HM; and two compilation flags: NO_EXT_KEYS, _CHAR_UNSIGNED. WATCOM C 386 (in addition to above for MSC compatibility) defines more model specifications: __FLAT__, __SMALL__, __MEDIUM__, __COMPACT__, __LARGE__; a machine specifier: __386__; and the compiler ID: __WATCOMC__. ---------------------------------------------------------------------------- Warner Losh imp@Solbourne.COM My current compiler doesn't, but my last one did: VAX-C for VMS does: vax VAX vms VMS VAXC vaxc and maybe: VAXC$G_FLOAT ---------------------------------------------------------------------------- michi@ptcburp.ptcbu.oz.au (Michael Henning) You can add AIX for AIX version 2.1.0 and later (runs on IBM RT's). ---------------------------------------------------------------------------- John Hascall hascall@atanasoff.cs.iastate.edu They following are defined on my DECstation: unix bsd4_2 ultrix mips host_mips ! presumably for cross-development MIPSEL ! MIPS Endian Little (as opposed to MIPSEB [big]) LANGAUGE_C ! I guess you can run other languages through the ! preprovessor? ---------------------------------------------------------------------------- Paul Davey pd@x.co.uk Older Acorn RISC iX (bsd4.3) machines define "arm" Their newer compilers define "__arm" ---------------------------------------------------------------------------- Marcel-Franck Simon mingus@attunix.ATT.COM uts == Amdahl's UTS u3b == AT&T 3B20 u3b15 == AT&T 3B15 u3b2 == AT&T 3b2 ---------------------------------------------------------------------------- Amos Shapira amoss@batata.huji.ac.il.bitnet Following are strings defined by the /lib/cpp of SGI (Silicon Graphics): mips host_mips __EXTENSIONS__ (don't know what that means, maybe you can cross it with other machines). sgi ---------------------------------------------------------------------------- uunet.UU.NET!dptechno!dave (Dave Lee) Here is an excerpt from HP-UX 7.0 on a HP9000/345 system cc(1) man page. Native cc. operating system unix, __unix hardware hp9000s800, hp9000s500, hp9000s300, hp9000s200, hp9000ipc, __hp9000s800 __hp9000s300, hppa, __hppa UNIX systems variant PWB, __PWB, hpux, __hpux, _HPUX_SOURCE lint(1) lint, __lint ---------------------------------------------------------------------------- Tom Ploegmakers tomp@nikhefk.uucp I found the following in the sources on our gould (~= 4.3BSD) and 2.10BSD systems. I haven't checked on the ifdefs in the sources though. BSD2_10 BSD2_9 GOULD_PN gould interdata mc68000 mert os pdp11 sel sun tss vax Strings on /lib/cpp reveals on gould: GOULD_PN gould unix (hmm... there used to be 'sel' and 'selport' or something in it as well) on pdp11: BSD2_10 pdp11 unix on sun mc68000 mc68020 unix I'm quite sure the following will exist as well BSD4_3 ---------------------------------------------------------------------------- gordon@sneaky.lonestar.org (Gordon Burditt) __GNUC__ GNU C compiler __OPTIMIZE__ GNU C compiler with optimization turned on __STRICT_ANSI__ GNU C compiler with strict-ANSI mode turned on __CHAR_UNSIGNED__ GNU C compiler operating with unsigned characters Following predefined by Xenix/68000 System III compiler: M68000 processor type M_M68000 processor type unix os type M_XENIX os type M_SYS3 If compiling in System III mode (selection of include files, libraries, etc.) M_SYSIII If compiling in System III mode (selection of include files, libraries, etc.) M_V7 If compiling in Version 7 mode (selection of include files, libraries, etc.) M_BYTESWAP Byte order M_BITFIELDS compiler supports bitfields Gordon L. Burditt sneaky.lonestar.org!gordon ---------------------------------------------------------------------------- Hans Randgaard (hbr@elctr.dk) The apollo machines(DN3000, DN4000 etc.) have the constant: apollo defined. ---------------------------------------------------------------------------- Sean Fagan seanf@sco.COM SCO UNIX System V/386 Release 3.2 (tm, tm, tm, tm, tm, tm?) Development System Release 3.2.2 OMF code generation: M_XOUT COFF code generation: M_COFF Always defined: M_XENIX Unix 3.2 code generation: M_UNIX (Note that either of the first two can be used with the last.) If you have access to an SCO machine, do a 'cc -z foo.c' to see all of them; try the various other options as well... ---------------------------------------------------------------------------- Harm Van Houten unido!athen!hvh I am working on a Siemens MX300 with SINIX Version 5.2. It is a widespread *NIX machine in western europe and I found the following predefined : nsc32000 /* That's Hardware 'cause of National Semi 32332 or 32532 CPU */ ns32000 ns16000 D=sinix /* That's the name of the OS */ D=unix /* 'cause of compatibility */ ---------------------------------------------------------------------------- Mark Harrison harrison@necssd.NEC.COM >From "man cpp" on DEC 5810 MIPS Ultrix: The symbols predefined by this implementation are bsd4_2, ultrix, unix, mips, host_mips, and MIPSEL. >From "man cpp" on Sun 4/490: Operating System: ibm, gcos, os, tss and unix Hardware: interdata, pdp11, u370, u3b, u3b2, u3b5, u3b15, u3b20d, vax, mc68000, mc68010, mc68020, ns32000, iAPX286, i386, sparc, and sun UNIX system variant: RES, and RT The lint(1V) command: lint The symbols sun and unix are defined for all Sun systems, as is the value returned by the mach command. For Sun-4 systems, this value would be sparc. In addition, mc68000 is defined for Sun-2, Sun-3, and Sun-3x systems. ---------------------------------------------------------------------------- friedl@mtndew.Tustin.CA.US (Steve Friedl) What fun list! I have found many myself and am getting more all the time: unix almost everybody u3b AT&T 3B20 u3b2 AT&T 3B2 u3b5 AT&T 3B15 u3b15 AT&T 3B15 sparc Sun Sparcstations (same as sun4?) ns16000 Sequent Balance, Encore Multimax ns32000 Sequent Balance, Encore Multimax ns32032 Encore Multimax ns32332 Encore Multimax M68020 ARIX [?] tower32 NCR Tower tower32_700 NCR Tower tower32_800 NCR Tower mc68000 Sun 3 mc68020 Sun 3 hp9000_200 HP 9000 series 200 (68k family) hp9000_300 HP 9000 series 300 (68k family) hp9000s200 HP 9000 series 200 (68k family) hp9000s300 HP 9000 series 300 (68k family) hppa HP Precision Architecture (HP 9000 series 800) hp9000s800 HP 9000 series 8xx aiws IBM AIX - PC/RT AIX IBM AIX - PC/RT _IBMR2 IBM AIX - RS6000 i386 most 386 machines, Sequent Symmetry M_I86 Xenix 2.3.2 ----------------------------------------------------------------------- Warren Tucker, TuckerWare gatech!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US "Tell the moon; don't tell the March Hare: He is here. Do look around."
steve@wattres.UUCP (Steve Watt) (08/23/90)
In article <12313@paperboy.OSF.ORG> dbrooks@osf.org (David Brooks) writes: >In article <191@n4hgf.Mt-Park.GA.US> wht@n4hgf.Mt-Park.GA.US (Warren Tucker) writes: >>In article <185@n4hgf.Mt-Park.GA.US> I wrote: >>> I would like to compile a list of pre-defined manifest constants > >Contributors might want to use this shell script, which I extended [ chunks of script removed ] ># My "strings" will read stdin, but the manpage doesn't guarantee that. >cat $CC $CPP > $tfile1 >strings -a -2 $tfile1 | >sed '/^-D.*/s/^-D//' | >sort -u | >awk '/^[a-zA-Z_][a-zA-Z0-9_]*$/ { printf "#ifdef %s\nZ__Z%s\n#endif\n", $0, $0 }' > $tfile2 cat $CC and $CPP? I'm not allowed to do that, except as root or bin... -rwx--x--x 1 bin bin 62140 Aug 21 1989 /bin/cc -rwx--x--x 1 bin bin 39062 Aug 21 1989 /lib/cpp Which brings up what I consider to be a strange point: Why is it that most *NIX vendors ship systems with all the files in /bin and /usr/bin world- readable? It seems to me that they only need to be world-executable... And I could imagine someone learning some unpleasant things with a dis- assembler and some program that does important things... (/bin/passwd, maybe? naah...) OBTW: SCO ships things with 711 permissions, unless it's a shell script. Interesting, since they seem to be more concerned about security than most... Followups to comp.unix.questions, since this ain't C. -- Steve Watt ...!claris!wattres!steve wattres!steve@claris.com also works Don't let your schooling get in the way of your education.
tchrist@convex.COM (Tom Christiansen) (08/23/90)
In article <595@wattres.UUCP> steve@wattres.UUCP (Steve Watt) writes: |Which brings up what I consider to be a strange point: Why is it that most |*NIX vendors ship systems with all the files in /bin and /usr/bin world- |readable? It seems to me that they only need to be world-executable... Absurd. If you are relying about people not knowing about something for your security, than you've really no security at all. An unreadable binary is just annoying. You can't run what or strings on it. You can't adb it for your core dumps. But the point of it's being annoying secondary to the fact that it just doesn't make sense to rely upon ignorance to protect you. Security through obscurity isn't. --tom -- "UNIX was never designed to keep people from doing stupid things, because that policy would also keep them from doing clever things." [Doug Gwyn]
peter@ficc.ferranti.com (Peter da Silva) (08/24/90)
In article <595@wattres.UUCP> steve@wattres.UUCP (Steve Watt) writes: > Which brings up what I consider to be a strange point: Why is it that most > *NIX vendors ship systems with all the files in /bin and /usr/bin world- > readable? It seems to me that they only need to be world-executable... Security through obscurity is no security at all. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com