Want the word on __STDC__

Doug Gwyn gwyn at smoke.brl.mil
Mon Mar 11 06:08:17 AEST 1991


In article <668288453.3046 at mindcraft.com> fred at mindcraft.com (Fred Zlotnick) writes:
>>I have no problem with an otherwise CONFORMING implementation defining
>>__STDC__ to something other than 1, although why would it?  At least
>>that does not cause problems for strictly conforming applications.
>But it CAN cause problems (in addition to which, such an implementation
>is no longer conforming according to section 3.8.8): since we know that
>nonconforming implementations do in fact sometimes define __STDC__ to
>something other than 1, it would be useful to protect your code by using
>the test
>  #if __STDC__ == 1
>rather than
>  #ifdef __STDC__

The problem is that __STDC__ is likely to be set to 2 for an implementation
that conforms to an upward-compatible future revision of the C standard, so
#ifdef __STDC__ is the nicest way for current strictly-conforming programs
to accommodate both X3.159-1989 conforming implementations and our best
estimate of X3.159-199x conforming implementations.

Unfortunately, use of #if some_func(__STDC__) implies that the program is
trying to determine whether or not to use some system-specific substitute
code for features that may not exist in non-conforming implementations.
I believe the intention of X3J11 was that __STDC__ would be useful for
this purpose, but some C vendors have spoiled that by "helpfully" defining
__STDC__ in their non-conforming implementations.  In fact I have seen
__STDC__ defined as 1 in some non-conforming implementations.

The practical effect is that you have the non-conforming vendors to thank
for making __STDC__ useless in portable code.  Instead, you must somehow
devise your own solution to this environment testability issue.  What we
have done locally is for our universal configuration header <std.h> to
define a macro STD_C as either 0 or 1, 0 meaning not a conforming
implementation and 1 meaning conforming to X3.159-1989.  (Other values
reserved for possible future revisions of the standard.)  One of the first
steps in porting software is to edit <std.h> to correctly set STD_C as
well as some other system-dependent standard macros etc.



More information about the Comp.std.c mailing list