Xref: utzoo comp.os.os2:328 comp.lang.c:24278 comp.std.c:2233 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde!uunet!samsung!aplcen!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.os.os2,comp.lang.c,comp.std.c Subject: Re: MSC __STDC__ strange value Message-ID: <11744@smoke.BRL.MIL> Date: 5 Dec 89 16:58:15 GMT References: <223@bohra.cpg.oz> Reply-To: gwyn@brl.arpa (Doug Gwyn) Followup-To: comp.os.os2 Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 20 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 , is STD_C, and it can be forcibly configured to indicate the right thing separately for each supported C environment.