Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!ncar!gatech!udel!rochester!pt.cs.cmu.edu!k.gp.cs.cmu.edu!jgm From: jgm@k.gp.cs.cmu.edu (John Myers) Newsgroups: comp.std.c Subject: Re: __STDC__ and non-conforming ANSI C compilers Message-ID: <4055@pt.cs.cmu.edu> Date: 18 Jan 89 21:43:16 GMT References: <9405@smoke.BRL.MIL> <8741@megaron.arizona.edu> <9415@smoke.BRL.MIL> Organization: Carnegie-Mellon University, CS/RI Lines: 35 In article <9415@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) writes: >I consider the "cc -DDEBUG" issue negotiable, since it takes an >explicit user action to violate the standard constraint, so perhaps >it is appropriate to place the burden of responsibility on the user >in such a case. For example, the compiler documentation might say: >"Although __STDC__ is always 1, if you predefine macros then you do >not have a Standard-conforming implementation, so beware!" By the same argument, "cc -standard-extensions" (which can be thought of as prepending "#define asm __builtin_asm", "#define unix" and other such stuff to the source file) could legitimately have __STDC__ predefined. The fact that most implementations will use something like the absence of the switch "-strict-ansi" to do this is somewhat irrelevent. Namespace pollution can hardly be considered grounds for undefining __STDC__. As has been mentioned before, __STDC__ is useless for dealing with pollution. There's no strategy one can use on the other side of the #else--either one is going to get burned or one is not. With such things as token-pasting, , and function prototypes, one can use traditional methods (Reiser hacks, , and old-style declarations) on the other side of the #else and have an extremely good chance of its working. I agree that defining __STDC__ to be 0 is a crock. (On the issue of libraries, a compiler could do the same thing as "gcc -ansi -pedantic" and claim to be a "conforming freestanding implementation." Who says there are no subsets of conformance?) -- _.John G. Myers Internet: John.Myers@cs.cmu.edu (412) 268-5655 LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up "The datefield parameter is a six byte, null-terminated string encoding the UNIX date in base 64." -- Andrew Message System documentation. --