__STDC__ and POSIX

[Doug Gwyn]

In article <866 at auspex.UUCP> guy at auspex.UUCP (Guy Harris) writes:
>when he meant
>>mean anything from "they define 'fileno' as a macro in <stdio.h>" to

Ok, I used fdopen() as my example of a POSIX name in <stdio.h>
instead of fileno() but the principle is the same.  These are
simply prohibited from being visible there in an ANSI C Standard
conforming implementation.  When the POSIX conflict with this
(extremely important, I think) general anti-pollution principle
was discovered, there was much frantic activity (since both
groups were meeting at the same time in different locations) to
try to work out a resolution.  These issues were not getting
resolved satisfactorily, and X3J11 sent a letter to P1003 with
X3J11's recommendation for how to best provide extensions like
this while remaining ANSI C Standard conformant.  (Basically the
idea was to require some symbol be defined before inclusion of a
standard header to enable the extensions; this symbol could have
been predefined in POSIX environments, to make it convenient.)
The actual scheme adopted in the final IEEE Std 1003.1 wasn't
quite what X3J11 had suggested; in fact it's sort of the converse.
They permit an application (NOT the implementation) to define the
macro _POSIX_SOURCE, which (a) makes available POSIX extensions
and (b) removes unconstrained extensions that Std 1003.1 would
otherwise have permitted in headers.  However, the intent appears
to be that POSIX-mandated extensions be available in the headers
even when _POSIX_SOURCE is NOT defined by the application, and
that contradicts ANSI C.

I think the logical consequence of all this is that in a
simultaneously ANSI C and IEEE 1003.1 conforming implementation,
applications would have to be sure to defined _POSIX_SOURCE if
they want to get at the POSIX-specific symbols in those headers
specified by the C Standard.  This is obviously a nuisance, and
consequently it is probable that there will be few attempts to
provide simultaneously-conforming implementations and fewer
attempts on the part of applications to use them.  This is a
real lossage.

My hope is that in the UNIX world the following slightly
cheating position will become widely adopted as a compromise
solution of most benefit to the programmer who is also concerned
with portability issues:

	The new default compilation environment predefines
	_POSIX_SOURCE "on behalf of the application", i.e. it is
	NOT considered as being provided by the official
	"implementation" but by the "program" being compiled.

	The shared standard headers key on _POSIX_SOURCE to enable
	the POSIX extensions beyond the ANSI C specification.

	Except for the header extensions enabled by _POSIX_SOURCE,
	the ANSI C Standard is obeyed.

	__STDC__ is defined as 1.

As an acceptable but slightly less convenient alternative that can
be coped with easily by POSIX applications adding -D_POSIX_SOURCE to
CFLAGS in Makefiles:

	The new default compilation environment does NOT predefine
	_POSIX_SOURCE.

	The shared standard headers key on _POSIX_SOURCE to enable
	the POSIX extensions beyond the ANSI C specification.

	The ANSI C Standard is obeyed.

	__STDC__ is defined as 1.

The key to this is that, because the "program" is defining the
identifier _POSIX_SOURCE, which is in the name space reserved for
implementations, technically by the ANSI C Standard the realm of
"undefined behavior" has been entered.  Basically, POSIX
implementations would define the behavior in this case to be that
outlined above.

This solution does NOT work if it is the "implementation" that is
considered to be defining _POSIX_SOURCE.