karl@haddock.ima.isc.com (Karl Heuer) (05/27/89)
In article <8530@chinet.chi.il.us> saj@chinet.chi.il.us (Stephen Jacobs) writes: >Defining __STDC__ as zero is a very reasonable way of telling a program that >you don't comply with the standard. But not nearly as reasonable as undefining it completely, which would work with *both* "#if" and "#ifdef", and which would be consistent with all the compilers that were written before X3J11 invented the __STDC__ symbol. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
bill@twwells.uucp (T. William Wells) (05/28/89)
In article <13475@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
: But not nearly as reasonable as undefining it completely, which would work
: with *both* "#if" and "#ifdef", and which would be consistent with all the
: compilers that were written before X3J11 invented the __STDC__ symbol.
The ANSI standard applies only to implementations and programs
claiming conformance to it. Who should care what others do? If you
are writing programs that have to check the implementation for
conformance, you had just better only check for __STD__ == 1.
Anything else is just damn lazyness on your part.
If you are writing code that has to deal with preprocessors that will
complain about #if __STDC__ == 1 when __STDC__ is undefined, add this
to the top of your code:
#ifndef __STDC__
#define __STDC__ 0
#endif
Then wherever you need to test for ANSI conformance, you can just
test for __STDC__ == 1 without worrying about __STDC__ being
undefined at that point.
---
Bill { uunet | novavax } !twwells!billgwyn@smoke.BRL.MIL (Doug Gwyn) (05/28/89)
In article <1000@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: >The ANSI standard applies only to implementations and programs >claiming conformance to it. Who should care what others do? Developers of applications care, that's who. We need a reliable way of testing for a Standard-conforming implementation. __STDC__ was supposed to be the way. >If you are writing programs that have to check the implementation for >conformance, you had just better only check for __STD__ == 1. Unfortunately, vendors of non Standard-conforming C implementations have already been defining __STDC__ as everything under the sun, including 1. This does piss me off... We went through this discussion a few months ago. The inevitable outcome seems to be that, given the lack of vendor restraint necessary to make __STDC__ serve its intended purpose, application code has to provide its own arrangements for such configuration information. For example, my standard configuration header <std.h> now includes an appropriate definition of my own macro STD_C which I use the way that __STDC__ was intended to be used.
karl@haddock.ima.isc.com (Karl Heuer) (06/01/89)
In article <1000@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: >[You could, if necessary,] add this to the top of your code: > #ifndef __STDC__ > #define __STDC__ 0 > #endif I think that, instead, I'll add the equivalent of #if defined(__STDC__) && __STDC__ <= 0 #undef __STDC__ #endif until someone decides just what __STDC__==0 is supposed to mean. Does MWC, running on a non-UNIX system, predefine `unix' to be `0'? Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
bill@twwells.uucp (T. William Wells) (06/04/89)
In article <13522@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: : In article <1000@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: : >[You could, if necessary,] add this to the top of your code: : > #ifndef __STDC__ : > #define __STDC__ 0 : > #endif : : I think that, instead, I'll add the equivalent of : #if defined(__STDC__) && __STDC__ <= 0 : #undef __STDC__ : #endif : until someone decides just what __STDC__==0 is supposed to mean. The problem with that is that there are still an appreciable number of compilers that don't do defined(). Of course it could be done as: #ifdef __STDC__ #if __STDC__ <= 0 /* Or maybe even __STDC__ != 1 ? */ #undef __STDC__ #endif #endif (But if you want portability to compilers without #if, you are *really* screwed!) --- Bill { uunet | novavax } !twwells!bill
rec@elf115.uu.net (Roger Critchlow) (06/05/89)
In article <13522@haddock.ima.isc.com>, karl@haddock.ima.isc.com (Karl Heuer) writes: > I think that, instead, I'll add the equivalent of > #if defined(__STDC__) && __STDC__ <= 0 > #undef __STDC__ > #endif Sorry, you aren't allowed to #undef __STDC__. "The rule that these macros may not be redefined or undefined reduces the complexity of the name space that the programmer and implementor must understand;" [Rationale for dpANS C, 13-May-88, p. 67] > until someone decides just what __STDC__==0 is supposed to mean. It means that MWC does not claim dpANS conformance. The preprocessor conforms to dpANS in all respects except for the value of __STDC__. Since this makes it behave differently than previous versions of the preprocessor, it seemed reasonable to give some indication of the fact. The Rationale suggested that: "This macro should be of use in the transition toward conformance with the Standard." [Ibid., p. 68] so I made use of it. Since the Rationale suggested that "future versions of the Standard could define [ __STDC__ ] as 2, 3, ..." [Ibid.] I should have known right off that everyone would poll its value with #ifdef. :-) I missed that clue and the deed was done by the time everybody's C magazines were cranking out examples filled with #ifdef __STDC__ conditionals. I am sorry for the inconvenience which my perverse interpretation has caused users of the MWC compiler. > Does MWC, running on a non-UNIX system, predefine `unix' to be `0'? No, MWC only runs on non-UNIX systems, it never defines unix to be anything. -- rec@elf115.uu.net == uunet!elf115!rec == Roger Critchlow, Sea Cliff, NY --
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/05/89)
In article <13522@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: > #if defined(__STDC__) && __STDC__ <= 0 > #undef __STDC__ > #endif >until someone decides just what __STDC__==0 is supposed to mean. I don't know about the particular compiler in question, but I don't think you're supposed to be able to #undef of re-#define the __????__ macros. That's why I ended up using my own symbol STD_C instead of trying to "fix" the vendor's __STDC__ in general.
karl@haddock.ima.isc.com (Karl Heuer) (06/06/89)
In article <118@elf115.uu.net> rec@elf115.uu.net (Roger Critchlow) writes: >In article <13522@haddock.ima.isc.com>, karl@haddock.ima.isc.com (Karl Heuer) writes: >> I think that, instead, I'll add the equivalent of [#undef __STDC__] > >Sorry, you aren't allowed to #undef __STDC__ [according to the Standard]. A non-conforming compiler is not bound by the Standard anyway; it knows no law save that of the marketplace. In any case, when I said "the equivalent of", I meant to include measures as drastic as binary-patching the compiler. >> until someone decides just what __STDC__==0 is supposed to mean. > >[It apparently means that the preprocessor agrees with the ANSI specs] I'm perfectly willing for it to mean that, but there has to be a consensus, if not a formal standard. Should I be using #ifdef when I want to test the preprocessor, and #if when I want to test any other part of the compiler? What if some other vendor uses __STDC__==0 to mean that their compiler understands prototypes but not token-pasting? >The Rationale suggested that: "This macro should be of use in the transition >toward conformance with the Standard." It's certainly of such use to users. I doubt that it was intended to be used transitionally by implementors. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
pardo@june.cs.washington.edu (David Keppel) (06/06/89)
bill@twwells.UUCP (T. William Wells) writes: >#if __STDC__ <= 0 /* Or maybe even __STDC__ != 1 ? */ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ No. Future versions of ANSI C may use 2, 3, etc. Your code will then start to break on newer compilers... ;-D on ( An issue of style? Gesundheit ) Pardo -- pardo@cs.washington.edu {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
diamond@diamond.csl.sony.junet (Norman Diamond) (06/07/89)
bill@twwells.UUCP (T. William Wells) writes: >>#if __STDC__ <= 0 /* Or maybe even __STDC__ != 1 ? */ In article <8465@june.cs.washington.edu> pardo@cs.washington.edu (David Keppel) writes: >No. Future versions of ANSI C may use 2, 3, etc. Your code will then >start to break on newer compilers... Maybe yes. Your code will break in newer versions anyway. Just ask anyone who has had to revise code to work with a standardization of existing practice, such as Fortran, Cobol, or C. -- -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net) The above opinions are my own. However, if you're reading this at Waterloo or Stanford, then their administrators must have approved of these opinions.
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/08/89)
In article <10334@socslgw.csl.sony.JUNET> diamond@csl.sony.junet (Norman Diamond) writes: >Your code will break in newer versions [of standard-conforming C >compilers] anyway. Standard-conforming code is not expected to be rendered non-conforming in the next revision of the C Standard. Any area where there was some sentiment that it might was flagged as an "obsolescent feature" in the current Standard, which should serve as sufficient warning to people to avoid relying on their long-term stability. All other features should remain in C "forever".
dik@cwi.nl (Dik T. Winter) (06/09/89)
In article <10378@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > In article <10334@socslgw.csl.sony.JUNET> diamond@csl.sony.junet (Norman Diamond) writes: > >Your code will break in newer versions [of standard-conforming C > >compilers] anyway. > > Standard-conforming code is not expected to be rendered non-conforming > in the next revision of the C Standard. Any area where there was some > sentiment that it might was flagged as an "obsolescent feature" in the > current Standard, which should serve as sufficient warning to people > to avoid relying on their long-term stability. Harumph. Yeah, we know about obsolescent features. See Fortran. -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax
nevin1@cbnewsc.ATT.COM (nevin.j.liber) (06/09/89)
In article <10378@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: |Standard-conforming code is not expected to be rendered non-conforming |in the next revision of the C Standard. Any area where there was some |sentiment that it might was flagged as an "obsolescent feature" in the |current Standard, which should serve as sufficient warning to people |to avoid relying on their long-term stability. All other features |should remain in C "forever". Does this mean the ANS C v2 won't have any new keywords?? I doubt it. Yet adding new keywords has a possibility of breaking existing code. As a matter of fact, There is terribly little that can be added to C which will not break existing pANS C v1 code (offhand, the only thing I can think of is something on the order of allowing a comma after the last element in declarator list). Still, it will probably be 99% compatible. -- NEVIN ":-)" LIBER AT&T Bell Laboratories nevin1@ihlpb.ATT.COM (312) 979-4751
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/09/89)
In article <1188@cbnewsc.ATT.COM> nevin1@ihlpb.ATT.COM (nevin.j.liber) writes: >Does this mean the ANS C v2 won't have any new keywords?? I doubt it. Certainly, adding keywords risks breaking code that used them as identifiers. I don't envision keywords being added, although something like "noalias" might be adopted for __STDC__==2. >As a matter of fact, There is terribly little that can be added to C which >will not break existing pANS C v1 code ... Several vendors have found conforming ways to extend the language specified by Standard C. Other ways one might think of currently require a diagnostic, which does not pose a compatibility problem were the current constraints to be relaxed. GCC supports several such syntactic extensions.
ralph@nastassia.laas.fr (Ralph-P. Sobek) (06/12/89)
Since the previous postings were discussing what one complier supports or does not support, I have a simple question. Is it true that MWC does not support the IEEE floating point standard? Is it in the queue? According to our local ST mag (precisely: ST Magazine), they stated that MWC uses the DEC standard. Ralph P. Sobek Disclaimer: The above ruminations are my own. ralph@laas.laas.fr Addresses are ordered by importance. ralph@laas.uucp, or ...!uunet!mcvax!laas!ralph If all else fails, try: SOBEK@FRMOP11.BITNET sobek@eclair.Berkeley.EDU
kens@atari.UUCP (Kenneth Soohoo) (06/13/89)
In article <381@laas.laas.fr> ralph@laas.laas.fr (Ralph P. Sobek) writes: > >Since the previous postings were discussing what one complier supports >or does not support, I have a simple question. > >Is it true that MWC does not support the IEEE floating point standard? >Is it in the queue? According to our local ST mag (precisely: ST >Magazine), they stated that MWC uses the DEC standard. > Yes, Ralph, MWC _does_ support the DEC format, which isn't a heck of a lot of help with the MC6881 floating point co-processor board, which uses IEEE standard floating point. As far as _I_ know, MWC has plans to support IEEE in the near future (i.e. "we're working on it, OK???"). You should check out, oh, any number of other compilers if you _really_ need IEEE... Aztec, Alycon... ;-) Oh, and regarding the expansion bus which the '881 sits on in a Mega, it'd be _really_ hard to make the equivalent slot for a 520/1040 style machine, sorry. -- Kenneth Soohoo {ames,imagen,portal}!atari!kens Atari Engineering "So Atari doesn't necessarily agree with me, so what!"
n62@nikhefh.hep.nl (Klamer Schutte) (06/14/89)
In article <1557@atari.UUCP> kens@atari.UUCP (Kenneth Soohoo) writes: >In article <381@laas.laas.fr> ralph@laas.laas.fr (Ralph P. Sobek) writes: >>Is it true that MWC does not support the IEEE floating point standard? >Yes, Ralph, MWC _does_ support the DEC format, which isn't a heck of a lot >You should check out, oh, any number of other compilers if you _really_ need >IEEE... Aztec, Alycon... ;-) Oh, and regarding the expansion bus which the Or you can try TURBOC; it is nice, and support IEEE (extended format, 80 bits for calculations and normal, 32 bits for float). Klamer PS 1 I do not have a 6888n; so i haven't tried whether it is really IEEE PS 2 I am not connected to Borland, the Turbo company -- ________________________________________________________________________________ Klamer Schutte mcvax!nikhefh!{n62,Schutte} {Schutte,n62}@nikhefh.hep.nl
kbad@atari.UUCP (Ken Badertscher) (06/16/89)
In article <211@nikhefh.hep.nl> n62@nikhefh.hep.nl (Klamer Schutte) writes: | In article <1557@atari.UUCP> kens@atari.UUCP (Kenneth Soohoo) writes: | >You should check out, oh, any number of other compilers if you _really_ need | >IEEE... Aztec, Alycon... | | Or you can try TURBOC... Or you can use Laser C. Laser supports IEEE format reals, and the software FP libraries are very very fast. Megamax has recently added 68881 support in their FP libraries, too! -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include <disclaimer>