>> And, personally, I have no time for arguments like ``but that's in a
>> system header file, so it's different''.  If the ANSI translator
>> gets to see it, and it's not ANSI C, then the program (translation
>> unit?) isn't conforming, period.
> I agree with this statement.  Code is either conforming or it isn't.

Not quite.  At least with respect to the Standard C header files like
<stdio.h>, there is no guarantee they exist as files, that they contain
anything resembling C code if they do, etc.

If a C-standard-specified header like <stdio.h> happens to be
implemented as a file that contains something that, like
"typedef long long int __off_t;" (say), would be an error in user code,
the implementation is not thereby nonconforming, and most certainly
code that uses <stdio.h> is not thereby rendered nonconforming.  "Code
is either conforming or it isn't" is a bit too simplistic here - the
user code, which uses <stdio.h>, can be conforming even if the
preprocessed code would not be - "preprocessed code" need not even
exist; the preprocessor can be merged with the tokenizer....  And the
contents of <stdio.h>, if indeed it _has_ contents, are private to the
implementation and can be anything at all, as long as the semantics
from the point of view of code that #includes <stdio.h> are adhered to.

Arranging for the compiler to accept non-standard-C-code in a standard
header but not in user code is a quality-of-implementation issue; as
long as the diagnostic is a warning rather than an error, it is not a
conformance issue.

Or at least such is my understanding.  I'm sure seebs will be glad to
correct any mistakes I've made. :-)

> I've thought of a C implementation with really wonky but legal
> constraints would be a great test of portability.

I agree.  One of my "in my copious spare time" projects is a C
implementation that goes out of its way to break all the common
assumptions that nevertheless violate constraints.  For example,
pointer types would be machine addresses with constants added, the
constant being different for every distinct pointer type (char* and
void* special-cased, of course).  char *, and void *, would be larger
than other pointers.  Integers would be "odd" sizes, like a short
taking up two and a half chars, with the other half-char unused.
Conversion between integers and pointers would be deliberately bizarre
and non-information-preserving.  Etc, etc....  (It would probably be an
interpreter, not a compiler.)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu