__STDC__ and non-strictly conforming ANSI C compilers
Doug Gwyn
gwyn at smoke.BRL.MIL
Sat Dec 17 07:28:14 AEST 1988
In article <1988Dec15.183200.2395 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:
>A compiler which will correctly compile any strictly-conforming program,
>and will diagnose any violation of the standard, has every right to
>define __STDC__ as 1 no matter how many extensions it also accepts.
This is correct, and the point should be emphasized that there are
standard-conforming ways to add many common extended features; if
there is a standard-conforming way to implement them, then that
should be used, and __STDC__ continue to be defined (as 1).
One really easy way to continue to support such things as "near"
in a standard-conforming environment is to require the applications
that need these historical but non-standard features to #include a
header that the implementation provides to define them, e.g.
#include <brain-damaged.h> /* gets "near", etc. */
near int array[1000];
Of course what such a header would do is
#define near __near /* map to built-in conforming keyword */
As Henry pointed out, functions can be added to the standard C library,
so long as the implementation of the standard functions does not use them.
I have to disagree that defining __STDC__ as non-1 values, specifically
0, is a good idea. Since there is no standard meaning for that, the
only use in portable programming would be
#if __STDC__ == 1
which as I pointed out previously is quite undesirable.
#ifdef __STDC__
should suffice; however,
#if __STDC__
is what I use, just in case some implementation is stupid enough to
#define __STDC__ 0
for a non-conforming environment, but I hope that nobody does that.
More information about the Comp.std.c
mailing list