🚀 go-pugleaf

In article <11005@ulysses.homer.nj.att.com> jss@hector.UUCP (Jerry Schwarz) writes:
>Does the answer depend on which of the following commands is used
>to invoke the non-conforming compiler?

The implementation should not predefine __STDC__ when the compiler
or library are invoked in non-conforming ways.  I realize that that
means that
	ansi_cc -PREDEF near __near foo.c
would have to, because of the standard-violating predefinition of
a symbol not reserved for implementation use, turn off its
predefinition of __STDC__.  The same is true for
	ansi_cc -OPTIM darnell foo.c
(meaning, use the "future direction" suggestion for [] in formal
function parameters), or for anything else you allow to be done to
bring the compilation environment into non-compliance.  This
suggests that the "ansi_cc" documentation should clearly state that
the use if such options will render the compilation environment non
standard-conforming and that __STDC__ will not be predefined in
such a case unless the user adds "-PREDEF __STDC__ 1" to the other
options.  This places the responsibility for safe use of
non-conforming features firmly in the user's hands, rather than
the implementor predefining __STDC__ in a case where it could
cause a problem.

Of course you could supply a "nonansi_cc" command that, with
appropriate combination of options as documented in the ANSI C
conformance guide you provide, would become the official
standard-conforming invocation.  In fact one of the options
you could require the user to provide is "-D__STDC__=1".
That's a whole lot better than you deciding to have the compiler
itself lie about __STDC__ness.