__STDC__ and non-strictly conforming ANSI C compilers

[Doug Gwyn]

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.