__STDC__ and non-strictly conforming ANSI C compilers

[Doug Gwyn]

In article <11018 at ulysses.homer.nj.att.com> jss at hector.UUCP (Jerry Schwarz) writes:
>This is conforming (it may work on some conforming compilers) but not
>strictly conforming. It will fail on a conforming compiler that
>defines _BRAIN_DAMAGED  and doesn't like __far.  A conforming
>compiler is entitled to behave this way because you're stepping on
>its reserved namespace.

Yes, I know all that.  I had considered using BRAIN_DAMAGED instead,
but figured you would then ask how it got defined, and I didn't want
to get into that.  For purposes of the discussion, let's assume that
either every vendor with __far has agreed to predefine _BRAIN_DAMAGED,
or else change the name to something in the application's name space
and assume the application has arranged to enable it somehow.

Unfortunately, C has no way to test whether an identifier is already
typedefed.  There are numerous occasions when one wants to do that;
this was one of them.

The point of my example is that it is legitimate for me to treat "far"
as in the application's name space, if __STDC__ is set.

My swipe at AT&T was not "gratuitous".  Consider it a swipe at
Dennis if you want, for overloading "static" and "extern".  (They're
just the simplest C examples of problems brought on by lack of
orthogonality; there are many more in the UNIX C programming
environment.)  X3J11 had to work pretty hard in several areas to cope
with such problems; it would have been much better if they had been
handled right in the first place, when there was no existing practice
to protect.  Since we are in "the first place" with __STDC__, let's
try to get AT&T (and other vendors) to not try to multiplex meanings
onto it other than the one assigned by X3J11.