__STDC__, _POSIX_SOURCE, etc.

[Bob Lenk]

In article <9458 at smoke.BRL.MIL> gwyn at smoke.BRL.MIL (Doug Gwyn ) writes:

> Yes, it's a difficult situation, but technical solutions are possible.
> ...
> I'm appending the text of the letter to this (long) article.

Thanks for posting the letter.  It did help clarify some of your points
to me.

>                                                        the definition
> of _POSIX_SOURCE in 2.8.2 makes it appear that "the symbols defined by
> this standard" will NOT be provided by the environment unless the
> _POSIX_SOURCE feature-test macro is "present" in the program.

The closest wording I can find to this is:

	Feature test macros shall be defined in the compilation of
	an application before a #include of any header where ...

I understand this to permit a "#define _POSIX_SOURCE" in the source,
a "-D_POSIX_SOURCE" on the command line, or an invocation of a compiler
that predefines _POSIX_SOURCE.

>                                                                Further
> it is defined to prohibit extensions in a header for which "no explicit
> constraint on the form of the name is provided by this standard", which
> I take to mean that, for example, <sys/times.h>'s declaration of
> "struct tms" shall not contain any members other than those enumerated
> in Section 4.5.2.2.  I think actually it was intended to permit others
> of the form tms_* even when _POSIX_SOURCE is in effect, and not names
> of other forms, but I don't see any such "explicit constraint" and so
> even additional tms_* names seem to be outlawed under _POSIX_SOURCE --

I see how this interpretation is reasonable.  The statement seems to
contradict one made shortly prior to it:

	Implementations may add members to a structure or union
	without controlling the visibility of those members with
	a feature test macro.

Doug's interpretation is probably the best resolution of the apparent
contradiction.  My interpretation, somewhat educated by discussion with
the author of this section, is that the statement limiting the extensions
made visible by _POSIX_SOURCE is poorly worded, and that the intention
was to permit _POSIX_SOURCE to make any additional fields in structures
visible.  This is, of course, *not* an official interpretation of
IEEE Std 1003.1-1988.  An official interpretation can be given only
in response to a formal request to the IEEE; any interested party can
make such a request.  I will suggest that the 1003.1 working group
consider clarification of this wording in a supplement to the standard.

> >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).
> 
> I'll be happy if that is one generally accepted consequence.
> Is this really intended to take precedence over the statement in the
> definition of _POSIX_SOURCE that "the symbols defined in this standard
> will be provided by the environment"?

I don't understand why any precedence is needed.  By seeing to it that
_POSIX_SOURCE is defined, the program indicates that it "expects the
symbols defined by this [1003.1] standard will be provided by the
environment."  Since some of "the symbols defined by this standard" are
symbols not defined by the C Standard (ANSI C-prohibited extensions), it
follows that _POSIX_SOURCE turns on those ANSI C-prohibited extensions.

> I'm sure that the idea of "feature test macros" to enable visibility
> of such extensions is a good idea.  Of course even better is isolating
> the extensions by giving them their own headers.  The important
> portable-programming requirement is that the PROGRAM must take
> explicit action for such additional identifiers to become usurped for
> use by the extension(s).  This conflicts with the natural goal of
> vendors who wish to have existing customer applications compile
> unchanged in the new, standard-conforming environment.

There is no conflict necessary.  A vendor can supply a backward
compatible invocation of a compiler that pre-defines whatever feature
test macros are needed to make all old symbols visible.  Then one
additional invocation of an ANS-compatible compiler is also supplied.
>From that point the user can build any environment by defining
appropriate feature test macros.  The vendor can also choose to make it
easy to invoke the compiler with selected combinations of feature test
macros defined.

> >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.
> 
> The suggestion was made before, more than once, but nobody was able to
> figure out a good way to specify such a notion in proper standards
> terms.

Perhaps the best way would be to suggest guidelines for the use of
__STDC__ in the rationale.  This is along the lines of what Dave Prosser
is suggesting (though I'm not sure I agree with him on the specific
content of the guidelines).

>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).
> 
> I can't imagine any useful way of doing this particular test.  There
> probably should have been a POSIX equivalent of __STDC__ for this...

What's wrong with

	#include <unistd.h>
	#ifdef _POSIX_VERSION

or, for those concerned with implementations conforming to unapproved
drafts:

	#include <unistd.h>
	#if _POSIX_VERSION >= 198808L

>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.

> So I think historically there were several reasons for the situation.

I agree, and I think you've mentioned some of the most important ones.

> >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.
> 
> Several attempts were made to explain the significance of the name
> space guarantees.

I think there are problems with both of the standards not being clear
enough to those who weren't intimately involved with a specific part.
This is difficult to avoid, and I realize Doug is one who put a lot
of good effort into avoiding it.  I can't think of any solution beyond
broader involvement in the creation and review of the standards.

>		========== X3J11 letter to P1003: ==========

I believe that the 1003.1 solution with _POSIX_SOURCE is better than the
one suggested in the letter (or any other alternative I've seen).  The
only real difference I see in the solution suggested in the letter is
that it uses the symbol _POSIX_VERSION rather than _POSIX_SOURCE, and
that _POSIX_VERSION is defined in <unistd.h>.  The stated benefit is
that the program does not have to be modified to #define _POSIX_SOURCE,
since _POSIX_VERSION is defined by the implementation.  In practice this
does not seem to be a real benefit, since it applies only to programs
that already #include <unistd.h> before #including any other header (or
at least any ANSI C related header); I doubt this covers any large
number of existing programs.  Any other program requires a source
change, which seems like no benefit over adding #define _POSIX_SOURCE.
Conversely, in existing UN*X environments, there are ways to define
_POSIX_SOURCE without modifying the source by use of the -D compilation
flag (and perhaps tools beyond that).  _POSIX_SOURCE has the additional
advantage that it can be extrapolated to a set of feature test macros
for all sorts of symbols defined by various standards, de-facto standards,
portability guides, and implementations.

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