Newsgroups: comp.std.c
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: __STDC__ and non-strictly conforming ANSI C compilers
Message-ID: <1988Dec15.183200.2395@utzoo.uucp>
Organization: U of Toronto Zoology
References: <3236@pegasus.ATT.COM>
Date: Thu, 15 Dec 88 18:32:00 GMT

In article <3236@pegasus.ATT.COM> hansen@pegasus.att.com writes:
>What do people think a compiler should do with __STDC__ if it is not
>strictly conforming? That is, if the compiler conforms to the spec, but has
>some of the "common" extensions? Examples are compilers which extend the
>31-character name limit to flexnames, permit additional keywords such as
>"far" and "near", or have additional functions available such as "read()"
>and "write()".

Much depends on *exactly* which extensions we are talking about, and
*exactly* how the compiler deals with them.  A compiler which will
correctly compile any strictly-conforming program, and will diagnose
any violation of the standard, has every right to define __STDC__ as 1
no matter how many extensions it also accepts.  Given the diagnostic
requirement, many extensions must draw warning messages, but there is
no requirement that a conforming implementation *reject* programs that
use extensions.

Mind you, it will be somewhat tricky for an implementation to conform
if it defines new keywords, since strictly-conforming programs may
quite legitimately use those words as identifiers.  It is possible that
an implementation might be able to cope with this by being clever and
adapting its behavior to the circumstances, given that strictly-conforming
programs will not be using those keywords in their special roles.

Pollution of the general-purpose name space, e.g. new reserved identifiers,
is a no-no for a conforming implementation.  This doesn't necessarily mean
that you can't supply new functions, but it does mean that nothing must go
wrong if the strictly-conforming program defines its own read() function
which is totally unrelated to the system one.

>... Each compiler offers different flavors (strictly
>conforming versus conforming with extensions) dependent on switches...

Uh, what is a "strictly conforming" implementation?  I find no such term
in the October draft.  There are conforming implementations (which accept
all strictly-conforming programs, and diagnose -- but don't necessarily
refuse to compile -- all violations of the ANSI syntax etc.) and non-
conforming implementations.  Period.

>    1)	Only the strictly conforming flavor will have __STDC__ defined, and
>	then to "1".
>
>    2)	In non-strictly conforming mode, __STDC__ will be defined but will
>	have a value of "0".
>
>    3)	In all modes, __STDC__ will be defined with the value of "1".
>
>Which choice should be the correct one? ...

Mode 3 is definitely wrong, since __STDC__ of 1 is supposed to indicate
a conforming implementation.  (I assume when you say "non-strictly
conforming", that means "non-conforming".)  Mode 2 is a very interesting
choice, given that it permits distinguishing "is this compiler modern,
accepting prototypes etc.?" from "is this a conforming implementation?"
(ask the former with "#ifdef __STDC__" and the latter with "#if __STDC__").
It appears to me that both modes 1 and 2 are consistent with the October
draft.  I would be very tempted to go with mode 2.
-- 
"God willing, we will return." |     Henry Spencer at U of Toronto Zoology
-Eugene Cernan, the Moon, 1972 | uunet!attcan!utzoo!henry henry@zoo.toronto.edu