Path: utzoo!attcan!uunet!lll-winken!lll-ncis!helios.ee.lbl.gov!pasteur!agate!bionet!csd4.milw.wisc.edu!mailrus!ulowell!masscomp!ftw From: ftw@masscomp.UUCP (Farrell Woods) Newsgroups: comp.std.c Subject: Re: __STDC__ and non-conforming ANSI C compilers Message-ID: <358@masscomp.UUCP> Date: 17 Jan 89 15:10:57 GMT References: <9391@smoke.BRL.MIL> <8731@megaron.arizona.edu> Reply-To: ftw@quasar.UUCP (Farrell Woods) Organization: MASSCOMP - Westford, Ma Lines: 60 In article <8731@megaron.arizona.edu> mike@arizona.edu (Mike Coffin) writes: >1) If the intent was that only conforming compilers define __STDC__, > why is this loophole in the standard? I.e., why does the standard > specify "1" as THE value for __STDC__? Is it too late to change > things, if the wording does not correspond to the intent? I think this was explained before. It is a mechanisim to allow future revisions to the standard. #if (__STDC__ == 1) will mean that this compiler (fully) conforms to what is currently the pANS. If a future standard should emerge, then the (fully) conforming compilers for that standard will set __STDC__ to 2, etc. Mr. Gwyn will correct me if I'm wrong ;-) >2) Why is #ifdef "as likely to be used" as #if? The latter is shorter > and tests for exactly what the standard specifies; the former is > longer and doesn't. It seems to me that using #ifdef for this > purpose is just a bug, pure and simple. Other have indicated that some compilers produce warnings if a undefined constant appears in a #if expression. This is weak, though. #ifdef __STDC__ is supposed to answer the yes/no question of whether this is a fully conforming compiler. #if __STDC__ will of course work, but it answers a slightly different question. >3) I suppose there is a need to determine whether the compiler is > exactly "conforming", although I'm not sure what you would do if it > wasn't. But the need is far more pressing for a flag that answers > the question "is this a K&R compiler or an ANSI compiler?" How do > we tell the difference between a K&R compiler and an ANSI compiler > that is invoked in such a way that it's nonconforming? (E.g., > "cc -DFOO".) Does the standard say anything about this? Shouldn't > we adopt some convention before we have chaos? I don't know if I quite understand the question. I don't believe that there is a "strict" interpretation of K&R; I suspect that is why we have X3J11 to help sort this out. If I invoke a conforming compiler with "cc -DFOO", but my program has #ifdef __STDC__ in it, how does this break conformance? >4) In view of the fact that "#ifdef __STDC__" doesn't tell us > anything, according to the standard (as I understand it), what is > wrong with using it to indicate "rough ANSI compliance"? That's the whole point: if vendors abuse __STDC__, then its meaning becomes eroded. __STDC__ only tell us something useful if vendors of non-conforing compilers respect its stated meaning. Obviously, X3J11 doesn't own the name "C" as a trademark, as the DoD does "Ada". Those of us who use C, and those who took their time to hammer out the pANS can only hope that vendors do not abuse __STDC__. When they do, we can raise a stink and threaten not to buy their compilers, etc., but we can't sue them. Here's another thing to think about. If each vendor that "almost" has all features of the pANS and decides to #define __STDC__ 0, how can my program figure out which subset of the pANS is in effect if I take the program from compiler A to compiler B? It really is a all-or-nothing shot. -- Farrell T. Woods Voice: (508) 692-6200 x2471 MASSCOMP Operating Systems Group Internet: ftw@masscomp.com 1 Technology Way uucp: {backbones}!masscomp!ftw Westford, MA 01886 OS/2: Half an operating system