ejp@bohra.cpg.oz (Esmond Pitt) (12/05/89)
For some strange reason, the MSC 5.1 compiler defines __STDC__ as 0, so #if __STDC__ ... #endif yields a different result from #ifdef __STDC__ ... #endif Why? -- Esmond Pitt, Computer Power Group ejp@bohra.cpg.oz
jeenglis@nunki.usc.edu (Joe English) (12/05/89)
ejp@bohra.cpg.oz (Esmond Pitt) writes: >For some strange reason, the MSC 5.1 compiler defines __STDC__ as 0, so >#if __STDC__ > >yields a different result from > >#ifdef __STDC__ > >Why? MSC (and many other compilers) support extensions to the Standard (far pointers, etc.) A common convention is to define __STDC__ as 1 when operating in strict-conformance mode (extensions disabled), and as 0 otherwise. That way you can use "#ifdef __STDC__" to determine if, e.g., function prototypes are available, and "#if __STDC__" to determine if the compiler is strictly conforming (no extensions, no surprises.) MSC's default mode probably leaves the extensions turned on. This is just a convention, by the way; it's not required by the Standard, and it's not strictly portable. It's not required because: if the compiler supports extensions, it's not strictly conforming, and if it's not strictly conforming, the Standard has no say over what it does. As far as I can tell, this practice follows both the letter and the spirit of the law, being useful without really breaking the rules. --Joe English jeenglis@nunki.usc.edu
is813cs@pyr.gatech.EDU (Cris Simpson) (12/05/89)
In article <223@bohra.cpg.oz> ejp@bohra.cpg.oz (Esmond Pitt) writes: >For some strange reason, the MSC 5.1 compiler defines __STDC__ as 0, so >Why? >Esmond Pitt, Computer Power Group >ejp@bohra.cpg.oz According to K&R2, (pg 233), __STDC__ must be defined, as well as (insert your own __ 's) LINE, FILE, DATE, TIME. However, since 5.1 is not ANSI, __STDC__ can't be 1. To me, it appears to be a ANSI compatible way to say that you're not ANSI conforming. Maybe (?) in MSC 6.0, __STDC__ will == 1. If not, I don't know what they're waiting for. Flames just enlighten me. cris -- Cris Simpson | Computer Engineer | No, No! Not THOSE chains! VA Rehab R&D Center | -K. Marx Atlanta,GA is813cs@pyr.gatech.edu |
hollen@eta.megatek.uucp (Dion Hollenbeck) (12/05/89)
From article <223@bohra.cpg.oz>, by ejp@bohra.cpg.oz (Esmond Pitt): > For some strange reason, the MSC 5.1 compiler defines __STDC__ as 0, so > > #if __STDC__ > ... > #endif This means: Take the DEFINED macro __STDC__ and test its value and return TRUE if non-zero and FALSE if zero > > yields a different result from > > #ifdef __STDC__ > ... > #endif > > Why? This means: Look to see if the macro __STDC__ is defined. If it is defined, return TRUE and if it is not defined return FALSE. The difference is the basic definition of #if and #ifdef. #if tests the value of a defined macro and #ifdef tests for its existence. In all code I have seen (I have lots of source to packages which I use) written to support several different compilers, the test always made is the #ifdef test. By the way, #define __STDC__ /* evaluates __STDC__ = 0 */ while #define __STDC__ 1 /* evaluates __STDC__ = 1 */ You will only get the #if test to be true if the macro IS DEFINED and IS DEFINED TO BE NON-ZERO. Hope this helps. Dion Hollenbeck (619) 455-5590 x2814 Megatek Corporation, 9645 Scranton Road, San Diego, CA 92121 uunet!megatek!hollen or hollen@megatek.uucp
henry@utzoo.uucp (Henry Spencer) (12/06/89)
In article <223@bohra.cpg.oz> ejp@bohra.cpg.oz (Esmond Pitt) writes: >For some strange reason, the MSC 5.1 compiler defines __STDC__ as 0, so > >#if __STDC__ >... >#endif > >yields a different result from > >#ifdef __STDC__ >... >#endif > >Why? Are you asking why the results are different, or why __STDC__ is defined oddly? If the former, __STDC__ is defined but 0, which means that #ifdef says "yes" but #if says "no". If the latter, consider the possibility that Microsoft is being stupid (heaven knows there is plenty of evidence for this in other areas...). Actually, one can weakly defend defining __STDC__ as 0 for a compiler which conforms to ANSI C in every way except for name-space pollution. Microsoft probably hasn't been smart enough to get that right, though. -- Mars can wait: we've barely | Henry Spencer at U of Toronto Zoology started exploring the Moon. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (12/06/89)
In article <223@bohra.cpg.oz> ejp@bohra.cpg.oz (Esmond Pitt) writes: >For some strange reason, the MSC 5.1 compiler defines __STDC__ as 0 ... >Why? Some C compiler vendors seem to think that they're doing the programmer a favor by predefining __STDC__ to a non-1 value to indicate that their compiler has "some" standard features but not full compliance. Typical features so indicated include support for function prototype declarations. However, since there is no way to tell just what part of the Standard is conformed to and what part isn't, such non-standard predefinition of __STDC__ is not very useful and, as you seem to have discovered, can actually get in the way of the programmer. We went through a discussion of this problem on comp.std.c several months ago. The conclusion seemed to be that programmers are going to have to invent their own symbol (presumably in a local standard configuration header) to serve the role that X3J11 had intended for __STDC__. My symbol, defined in <std.h>, is STD_C, and it can be forcibly configured to indicate the right thing separately for each supported C environment.
rhg@cpsolv.UUCP (Richard H. Gumpertz) (12/06/89)
In article <223@bohra.cpg.oz> ejp@bohra.cpg.oz (Esmond Pitt) writes: >For some strange reason, the MSC 5.1 compiler defines __STDC__ as 0, so ... >Why? On page "Update-54" the manual entry for __STDC__ reads: The integer constant 0. If equal to 1, this macro indicates full compliance with the ANSI proposed standard for the C programming language. I suspect Microsoft extrapolated from the standard's definition of __STDC__ in which future versions may define values such as 2, 3, etc. to mean revised C standards. They extrapolated backward to 0, meaning close to but not fully compliant. A plausible (but strange) hack I suppose. By the way, there is an interesting anomaly: The standard cannot say anything about whether __STDC__ is defined or what its value should be for non-conforming implementations -- it controls only the value for conforming ones! Hence, defining __STDC__ in a non-conforming implementation is perfectly legal so long as conformance is not claimed elsewhere. Of course, no sane implementor of a non-conforming compiler should define it as 1 (or greater, I suppose) unless he wants unhappy customers. Sigh. :-) -- =============================================================================== | Richard H. Gumpertz rhg%cpsolv@uunet.uu.NET -or- ...uunet!amgraf!cpsolv!rhg | | Computer Problem Solving, 8905 Mohawk Lane, Leawood, Kansas 66206-1749 | ===============================================================================
seanf@sco.COM (Sean Fagan) (12/06/89)
In article <223@bohra.cpg.oz> ejp@bohra.cpg.oz (Esmond Pitt) writes: >For some strange reason, the MSC 5.1 compiler defines __STDC__ as 0 >Why? Because things like extern int sprintf (char *, char *fmt, ...); won't work (you can't mix named and unnamed parameters in a prototype. Bummer). There are other things, but that's the one that has been in my mind most the past couple of days. -- Sean Eric Fagan | "Time has little to do with infinity and jelly donuts." seanf@sco.COM | -- Thomas Magnum (Tom Selleck), _Magnum, P.I._ (408) 458-1422 | Any opinions expressed are my own, not my employers'.
gwyn@smoke.BRL.MIL (Doug Gwyn) (12/06/89)
In article <841@megatek.UUCP> hollen@eta.megatek.uucp (Dion Hollenbeck) writes: >By the way, > #define __STDC__ /* evaluates __STDC__ = 0 */ Nope, with this definition a subsequent #if __STDC__ is an illegal program construct. If __STDC__ had been entirely undefined (rather than defined as an empty sequence of pp-tokens), then it is required to evaluate to 0, although perhaps some older compilers might not understand that and flag the #if as illegal even in that case.
cs169054@cs.brown.edu (Peter Golde) (12/06/89)
In article <223@bohra.cpg.oz> ejp@bohra.cpg.oz (Esmond Pitt) writes: >For some strange reason, the MSC 5.1 compiler defines __STDC__ as 0, so >Why? For a simple reason: there is no ANSI standard C yet (at least, last I heard.) It simply wrong to advertise conformance to a standard which doesn't even exist yet. For example, several detail of the draft standard have changed since MSC 5.1 was shipped. Thus, I argue that Microsofts definition is perfectly correct. Moral: don't confuse a *draft* standard with a real standard. They're quite different things. --Peter Golde (summer intern, Microsft Languages group)
ejp@bohra.cpg.oz (Esmond Pitt) (12/07/89)
In article <223@bohra.cpg.oz> ejp@bohra.cpg.oz (me) writes: >For some strange reason, the MSC 5.1 compiler defines __STDC__ as 0, so >... >Why? Some apparently illiterate posters have concluded that I don't know the difference between #if and #ifdef. I do, and my posting demonstrated so. This is truly annoying, folks. Please read. -- Esmond Pitt, Computer Power Group ejp@bohra.cpg.oz
leisner@arisia.Xerox.COM (Marty Leisner) (12/08/89)
In article <9692@pyr.gatech.EDU> is813cs@pyr.gatech.edu (Cris Simpson) writes: > According to K&R2, (pg 233), __STDC__ must be defined, as well as >(insert your own __ 's) LINE, FILE, DATE, TIME. However, since >5.1 is not ANSI, __STDC__ can't be 1. > __STDC__ only needs to be defined in a conforming compiler. It makes no sense to define __STDC__ to be 0 (except to confuse everyone). I work with a TI34010 and the TI supplied C compiler also defines __STDC__ to 0. At least with MSC, that's trying to be an ansi C compiler. TI only claims to be a K&R C compiler, if that much. This STDC == 0 stuff has caused nothing but grief. I'm close to the point to patching the preprocessor binary to remove this nonsense. marty leisner leisner.henr@xerox.com
tkacik@rphroy.UUCP (Tom Tkacik) (12/08/89)
In article <4714@arisia.Xerox.COM> leisner@arisia.UUCP (Marty Leisner) writes: >__STDC__ only needs to be defined in a conforming compiler. >It makes no sense to define __STDC__ to be 0 (except to confuse everyone). >I work with a TI34010 and the TI supplied C compiler also defines __STDC__ to 0. At least with MSC, that's trying to be an ansi C compiler. TI only claims to be a >K&R C compiler, if that much. >This STDC == 0 stuff has caused nothing but grief. >I'm close to the point to patching the preprocessor binary to remove this nonsense. At least it doesn't define __STDC__ to be 1. The Apollo C compiler claims to conform to K&R C, with a couple of ANSI C extensions, (ie. function prototypes). Because of this, they decided that __STDC__ should be defined as 1. There is absolutely no excuse for this! -- Tom Tkacik GM Research Labs, Warren MI 48090 uunet!edsews!rphroy!megatron!tkacik Work Ph: (313)986-1442 "Csh must go. This is non-negotiable!"
tony@tcom.stc.co.uk (Tony Oliver) (12/08/89)
In article <22283@brunix.UUCP> cs169054@cslab2b.UUCP (Peter Golde) writes: >In article <223@bohra.cpg.oz> ejp@bohra.cpg.oz (Esmond Pitt) writes: >>For some strange reason, the MSC 5.1 compiler defines __STDC__ as 0, so >>Why? > >For a simple reason: there is no ANSI standard C yet (at least, last I >heard.) > [remainder deleted] I beg to differ. I have a copy of the book "Standard C" by P. J. Plauger & Jim Brodie, 1989; (Microsoft Press, Programmer's Quick Reference Series, ISBN 1-55615-158-6). The back cover refers to the authors as, respectively, ...secretary of the ANSI-authorised C Programming Language Standards Committee and convener of the ISO committee on Standard C; ...chairman and convener of the ANSI-authorised C Programming Language Standards Committee. The acknowledgements section refers to the "efforts of all the members of X3J11 in producing a standard in the C programming language". The introduction states "The Standard C programming language described in this guide corresponds to the American National Standards Institute (ANSI) standard for the C language. An identical standard is currently under consideration by the International Standards Organization (ISO). This common standard was developed through the joint efforts of the ANSI authorized C Programming Language Committee X3J11 and the ISO authorized Committee JTC1 SC22 WG14". I take all these statements to indicate that, although the ISO standard was (at the time of publication) still being considered, the ANSI standard was in place (finalized and complete) and that this book describes conformance to this standard. To help with the original query that started this whole ball rolling, I quote from the Preprocessing section (Predefined Macros subsection): "The macro __STDC__ expands to the decimal integer constant 1. The translator [cpp or similar] should provide another value (or leave the macro undefined) when you invoke it for other than a Standard C environment". --- my [] brackets --- I thoroughly recommend this book (a 200-page paperback) and urge any serious C programmers to obtain a copy. I have had many "definitive" guides and quick references before, but this one is the works as regards the ANSI (and hopefully ISO) standard. As an aside, I wish to point out that I am a novice to USENET and have only replied to the article in this conference. If anybody knows of another newsgroup that is sharing this debate (or would be interested anyway) would they post the above (or a summary) for other users' benefit. Thank-you.
seanf@sco.COM (Sean Fagan) (12/10/89)
In article <4714@arisia.Xerox.COM> leisner@arisia.UUCP (Marty Leisner) writes: >__STDC__ only needs to be defined in a conforming compiler. Section 3.8.8: "The following macro names shall be defined by the implementation: ... __STDC__ the decimal constant 1. (79) ... (79) Thus indicating a Standard-conforming implementation." (The (79) indicates a footnote number, of course). >It makes no sense to define __STDC__ to be 0 (except to confuse everyone). >This STDC == 0 stuff has caused nothing but grief. Possibly. I *like* it, and agree with it, although there is one major bug in MSC that I'd like to fix (dealing with prototypes with mixed named and unnamed parameters), but I can also agree with people who *don't* like it. Anyway, a conforming implementation will have __STDC__ defined, and will have, as it's value, the constant 1 (decimal, as opposed, I guess, to the octal constant 1 8-)). -- Sean Eric Fagan | "Time has little to do with infinity and jelly donuts." seanf@sco.COM | -- Thomas Magnum (Tom Selleck), _Magnum, P.I._ (408) 458-1422 | Any opinions expressed are my own, not my employers'.
henry@utzoo.uucp (Henry Spencer) (12/10/89)
In article <1311@islay.tcom.stc.co.uk> tony@htc1.UUCP (Tony Oliver) writes: >>For a simple reason: there is no ANSI standard C yet ... >I beg to differ. Unfortunately, the original poster is correct. Your request to differ is refused. :-) :-) Actually, you're both right, after a fashion. >I have a copy of the book "Standard C" by P. J. Plauger & Jim Brodie, 1989; >(Microsoft Press, Programmer's Quick Reference Series, ISBN 1-55615-158-6). >[assorted quotations from same deleted] The fact is, although the *content* of the C standard has been pretty much cast in concrete for some time, it is *not* yet an ANSI standard. The reasons are silly and procedural rather than rational. There is no serious doubt that the current document will become an ANSI standard in the near future with no significant changes of content, but that has not actually happened yet. There is no ANSI C standard, yet. However, given that there is no real uncertainty about the content of the forthcoming standard, it is arguably meaningful to talk about "ANSI standard C" as a language. -- 1755 EST, Dec 14, 1972: human | Henry Spencer at U of Toronto Zoology exploration of space terminates| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (12/11/89)
In article <1311@islay.tcom.stc.co.uk> tony@htc1.UUCP (Tony Oliver) writes: >I take all these statements to indicate that, although the ISO standard was (at >the time of publication) still being considered, the ANSI standard was in place >(finalized and complete) and that this book describes conformance to this >standard. When the book was written, it was expected that ANSI would have ratified the C Standard by the time the book appeared. However, a last-minute procedural delay has caused probable ratification to slip until January 1990 (last I heard). Details of this delay have been posted previously. Note, however, that the final proposed Standard has been stable for a year now, and during the lengthy delay we've all been proceeding on the assumption that it will eventually be ratified by ANSI.