__STDC__ and non-strictly conforming ANSI C compilers

[Jerry Schwarz]

In article <9167 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>Programmers are likely to use
>either
>	#if __STDC__
>or
>	#ifdef __STDC__
>to conditionalize sections of code based on "house C" vs.
>"standard C".  In fact I already use the former that way.
>I assume full ANSI C conformance when the test succeeds.
>I don't think I should have to write
>	#if __STDC__ == 1
>which would force me to perform massive edits when the next
>C standard bumps the value of __STDC__ to 2.

I agree that you should not have to test the value of __STDC__.  
But I reach an opposite conclusion about what vendors ought to
do. If I arrange that my code is conforming (or strictly
conforming according to taste) when __STDC__ is defined that is about
all I can do.  If I want to make an accomodation to house C then I
should test for something defined in the house C.  Knowing that an
implementation is not conforming is useless unless I know how it
fails to conform.

If a vendor offers both a conforming ANSI and variations, it is
reasonable  that a version containing extensions (e.g. new keywords)
also have __STDC__ set.  If I choose to compile with the version
with extensions then its probably because I want (some of) the extensions.
This means I must accept the burden of making the code work in the
presense of the extension.

Doug would seem to encourage code such as

	#ifdef __STDC__
		char* p ;
	#else
		near char* p ;
	#endif

I want to discourage such code.  The use of "near" ought to be
conditioned on some positive assertion about the compilation system,
not merely that it isn't conforming.

Jerry Schwarz
AT&T Bell Labs, Murray Hill