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