__STDC__ and non-conforming ANSI C compilers

[Bob Lenk]

> The problem is NOT in the __STDC__==1 (or ==2, etc.) domain;
> it's in the unstandardized domain, for which __STDC__ simply
> does not help

I agree, but I'd go one step further.  In practice the X3J11 work has
made the situation where __STDC__ is not defined worse.  Before X3J11
there was certainly chaos, but there were various assumptions that
generally held.  As X3J11 has defined new features that violate those
assumptions and implementors provide them piece-meal that chaos has
gotten more complex.  This is especially true if __STDC__ can't be
defined whenever the namespace is polluted, because that's such a common
and useful situation which won't go away with pre-ANSI compilers.

> >Now one form of "strict ANSI non-compliance" (i.e., the negation of
> >"strict ANSI compliance") that could be useful would be that exhibited
> >by an implementation that conforms to ANSI C except for POSIX items that
> >might get in the way.
> 
> There weren't supposed to be any of these!  As inheritor of the role
> of 1003.1/X3J11 liaison, I'm painfully aware of that; read on...
> 
> The main problem seems to be that vendors want to include their old
> extra UNIX cruft in <stdio.h> without requiring their customers to
> use a different form of compilation from the ANSI C mode.

It seems to me that a <stdio.h> defining non-ANSI symbols results in
"strict ANSI non-compliance" whether or not a separate compilation mode
was used.  The only ways for 1003.1 to have stayed within the strict ANSI
bounds would have to move things like fileno() out of <stdio.h> or to
rename them to something like __fileno().  Since the 1003.1 goals (like
X3J11's) included following existing practice, this wasn't realistic.
At this point 1003.1 seems to be in a "Catch 22" situation.  Folks want
something specified by the compiler rather than the application, but
then they claim that a compiler that usurps the namespace must not
define __STDC__.

>       _POSIX_SOURCE, a late invention to try to resolve the name space
> conflicts in standard headers that define things for both ANSI C and
> POSIX, was specified backward from what X3J11 had recommended;

I don't recall any recommendation from X3J11.  What was it?

>            _POSIX_SOURCE, specified as being supplied by the
> APPLICATION, not the implementation, was specified as turning OFF
> POSIX-permitted extensions, but what was really needed was a way to
> turn ON ANSI C-prohibited extensions,

Where do you read this?  I see in section 2.8.2.1:

	If there are no feature test macros present in a program, only
	the set of symbols defined by the C Standard shall be present.
	For each feature test macro present, only the symbols specified
	by that feature test macro plus those of the C Standard shall
	be defined when a header is included.

In other words, _POSIX_SOURCE (a feature test macro) does turn on
definition of symbols not defined by the C Standard (ANSI C-prohibited
extensions).

Perhaps you are thinking of section 2.8.2.2.  First of all, that section
only applies to common usage C, and thus has no bearing on ANSI C
environments.  Second, it defines only the state when _POSIX_SOURCE is
defined, not the state when it is not defined (which is outside the
scope of any standard) and thus not whether _POSIX_SOURCE has an
additive effect, a subtractive effect, or any effect at all.

>        and in any event the vendors don't want to tell their customers
> to #define _POSIX_SOURCE in order for their existing code to compile.

Vendors who want their customers' existing code to compile unchanged
will provide backward-compatible compilers and environments to permit
that.  The P1003.1 working group did not believe that many existing
programs would conform to the new standard with zero change.

> The simplest solution would have been:
> 	cc	# backward-compatible sloppy UNIX mess version
> 	acc	# ANSI-conforming version
> 	pcc	# POSIX- and ANSI-conforming version
> 	fcc	# like "pcc" but with extra ANSI-prohibited stuff.

If this is still under the assumption that 1003.1 preserved strict ANSI
C conformance, I don't see why pcc would be needed at all; it could be
synonymous with acc.  If we accept that (and the analogous relations
with other, future standards) as impossible, what happens when 1003.2
adds popen() to <stdio.h> and 1003.4 adds symbols to 1003.1 headers like
<fcntl.h> and <sys/stat.h>?  Do we add new commands like:

	p12cc	# 1003.1 and 1003.2 conforming
	p2cc	# 1003.2 conforming
	p14cc	# 1003.1 and 1003.4 conforming
	p124cc	# 1003.1, 1003.2, and 1003.4 conforming

The "feature test macro" approach introduced in 1003.1 seems to handle
this much more cleanly, with N names rather than up to 2**N names for N
standards.

>	cc	__STDC__ not defined
>	acc	__STDC__==1
>	pcc	__STDC__==1
>	fcc	__STDC__ not defined

I don't understand this at all (assuming pcc is needed at all - see
above).  From the ANSI C perspective, pcc and fcc should be identical;
they are ANSI C with a polluted namespace.  The fact that pcc has its
pollution defined by a clear standard while fcc doesn't makes no
difference here.

Practically I think that ANSI C should explicitly permit the namespace
to be used in any way explicitly or implicitly specified by the user, as
long as there is a clearly documented way to get a completely clean
namespace.  Thus invoking pcc or fcc or "acc -DFOO" as defined here
should leave __STDC__ == 1, as long as the effect on the namespace is
clearly documented.  As others have stated, the predefine is not at all
useful in dealing with namespace pollution, beyond (perhaps):

	#if !__STDC__
	#error
	#endif

> >The best I see that could be done here is to make a strong
> >recommendation that POSIX vendors define
> >__ANSI_C_EXCEPT_FOR_POSIX_STUFF__ (or some other specified name) to
> >match what __STDC__ would have been defined as had the "allow POSIX
> >stuff" flag not been given to the compiler.
> 
> Practically ANY de facto standard not involving __STDC__ would be fine
> so far as I'm concerned.  As it stands, we have no satisfactory
> solution.

I'm not sure what problem is being addressed here, but I think there are
solutions to all the real problems except one.  If an application is
compiled with the straight ANSI compiler, it can test __STDC__ for
whatever it is interested in.  It can define _POSIX_SOURCE itself if it
wants POSIX symbols.  If it wants to know whether POSIX is supported, it
can then test _POSIX_VERSION from <unistd.h> (although the include of
<unistd.h> may fail on a non-POSIX system, I doubt this would be an
issue to any application that cared about this question).  The only
unsolved problem is whether the compiler which (at least effectively)
pre-defines _POSIX_SOURCE can define __STDC__.  I repeat that from a
practical perspective I think it should, as long as there's a way to get
a truly clean namespace.

__ANSI_C_EXCEPT_FOR_POSIX_STUFF__ falls into exactly the same trap as
the different compiler names, when N standards enter the picture there
are up to 2**N possibly meaningful symbols.  We could add one symbol like
__ANSI_C_EXCEPT_POSSIBLE_NAMESPACE_ADDITIONS_AS_REQUESTED_IN_INVOCATION__.
My point is that such a symbol seems far more useful than the strict
__STDC__, and it makes more sense to make that the meaning of __STDC__.

1003.1 could have addressed this by requiring one of two symbols like
_POSIX_STANDARD_C or _POSIX_COMMON_C to be defined, but that really
seems to be redundant with the purpose of __STDC__, and in the scope of
a language standard rather than an OS standard.

> It's really unfortunate that 1003.1 didn't straighten out more of the
> name space problems historical UNIX has had.

I think it's unfortunate that X3J11 didn't consider that the C library
is (at least in some valid cases) a foundation upon which other
environments build rather than a complete environment, and thus didn't
allow for graceful additions to the namespace consistent with existing
practice.  If they had addressed the problem sufficently and explained
the solution clearly, there wouldn't be all this debate about how
1003.1, Microsoft, AT&T, et. al. are dealing with the situation.

		Bob Lenk
		hplabs!hpfcla!rml
		rml%hpfcla at hplabs.hp.com