Xref: utzoo comp.lang.c:19720 comp.std.c:1335
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!bloom-beacon!adam.pika.mit.edu!scs
From: scs@adam.pika.mit.edu (Steve Summit)
Newsgroups: comp.lang.c,comp.std.c
Subject: Re: __STDC__
Message-ID: <12378@bloom-beacon.MIT.EDU>
Date: 2 Jul 89 15:50:12 GMT
References: <225800190@uxe.cso.uiuc.edu> <10448@smoke.BRL.MIL>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 66

I don't want to open the whole __STDC__ can of worms again, but I
have two questions:

1. Is there anything to the argument that nobody should be
   setting __STDC__ to 1 yet, since the standard isn't approved,
   and that everyone should, at this point, be setting it to 0 to
   indicate as much conformance to the draft as they can manage
   (and not "we have prototypes and the useful stuff but not hair
   like trigraphs" or similar half-compliance schemes which have
   been so thoroughly denounced)?  (This may be a frivolous
   question; don't flame if you find it so.)
   
2. Why is it forbidden to re#define __STDC__?  In a previous
   article, I discussed needless restrictions, and this seems to
   me to be one.  Why shouldn't a program re#define __STDC__, if
   it really wants to and is prepared to accept the consequences?

   Why would a program want to, you ask?  In an open system, the
   burden of proof is on the implementor to show why a
   restriction is necessary, not on the user to provide a useful
   counterexample.

Even so, I can provide a realistic example of why mucking with
__STDC__ would be useful: suppose I am interested in keeping my
code compatible with earlier, non-ANSI compilers (a far from
hypothetical suggestion).  If my primary development machine uses
an ANSI compiler, I might from time to time want to check if the
changes and additions I have been making are (at least
syntactically) still usable on the non-ANSI machine, without
necessarily taking all of the code over to the old machine and
compiling it.  It seems natural to say

	cc -U__STDC__

yet this is forbidden.  It is claimed to make the compiler
writer's life easier, having perhaps something to do with vendor-
supplied header files, but even if the header files have #ifdefs
on __STDC__ in them (perhaps to make them usable with a non-ANSI-
compliant invocation mode) the old give-him-enough-rope-to-hang-
himself philosophy says that I ought to just get obscure errors
(if in fact there are obscure conflicts).  (No :-), I'm serious.)
Instead, the compiler writer, as I understand it, is obliged to
have code like

	cppdefine(name, value)
	char *name, *value;

	if(strcmp(name, "__STDC__") == 0 || strcmp(name, "__LINE__") == 0 ...)
		{
		error("illegal re#definition of %s", name);
		return ERROR;
		}

in the preprocessor.  I can maybe understand the prohibition on
re#defining __LINE__, since it may well be implemented strangely
(its value changes practically every time you expand it) and
re#defining it therefore ineffectual, but prohibiting changing
__STDC__ just keeps me from doing what I want to do without
affecting the compiler at all (other than adding an extra test).
I don't believe that it is the compiler (or preprocessor)
writer's job to protect the header file author from me; if I muck
with __STDC__ and it breaks a standard header file, that's my
problem, not the compiler's.

                                            Steve Summit
                                            scs@adam.pika.mit.edu