__STDC__

[david.f.prosser]

In article <12378 at bloom-beacon.MIT.EDU> scs at adam.pika.mit.edu (Steve Summit) writes:
>I don't want to open the whole __STDC__ can of worms again, but I
>have two questions:
>
>2. Why is it forbidden to re#define __STDC__?  In a previous
>   article, I discussed needless restrictions, and this seems to
>   me to be one.  Why shouldn't a program re#define __STDC__, if
>   it really wants to and is prepared to accept the consequences?

The pANS only requires that a portable (i.e. strictly conforming) program
must not have a #define or #undef for one of the predefined identifiers
or defined.  The reason why __STDC__ is included in the list of these
identifiers is mostly one of generality: it makes no sense (as you note)
to change the value of "generated" macros such as __LINE__, and __STDC__
is the only possible candidate for redefining for which a case can be made.
If the pANS were to allow the redefinition of __STDC__, then either some
behavior "loophole" would be required (this is actually the current status),
or some well-defined result would need to be defined.  The latter is most
likely not to be worth the trouble.

The pANS does not require a diagnostic message if an attempt is made to
violate this restriction.

It seems reasonable, to me, for the preprocessing phase to allow the
redefinition of __STDC__, but this is a "quality of implementation" issue.
Nevertheless, a portable program could use its own macro (MY__STDC__)
that is used to get the effect of __STDC__:

	#ifndef MY__STDC__
	# ifdef __STDC__
	#  define MY__STDC__ __STDC__
	# endif
	#else
	# undef MY__STDC__
	#endif

Then, with -DMY__STDC__, you get the "old fashioned" part of the code,
and with no option, you get MY__STDC__ as tracking the value of __STDC__.
For maximal portability, it can be argued that a prudent programmer will
isolate all uses of __STDC__ into a single spot so that the variations in
"conformance" can be managed.

Dave Prosser	...not an official X3J11 answer...