__STDC__ and POSIX

[Doug Gwyn]

In article <399 at jhereg.Jhereg.MN.ORG> mark at jhereg.MN.ORG (Mark H. Colburn) writes:
>It is possible, I think, to put together a header which conforms to
>both standards.   For example:
[universal defines]
>#ifdef _POSIX_SOURCE
[POSIX-specific defines]
>#endif /* _POSIX_SOURCE */

>In the example above, the POSIX related defines will only be used if
>_POSIX_SOURCE is defined.  Therefore, if it is not defined, there should be
>no namespace pollution.

Fine, and an implementation that simultaneously conforms to both standards
has to use a technique like that.  The practical problem is that many
POSIX vendors do not want to force their customers to #define _POSIX_SOURCE
in their source code in order for the POSIX definitions to become visible.
They rather prefer that these definitions be visible without the extra work
on the part of the application.  Mostly this is because they would like to
be able to use their new POSIX environment to compile existing UNIX
applications without having to change said applications.  <limits.h> is not
the best example of the problem; <stdio.h> is a better one.

>I would hope that ANSI is not attempting to say that the only materail that 
>is allowed in an ANSI C conforming header is that material which is in the
>ANSI C standard.

No, but any extra stuff in the standard headers must either use only
those identifiers reserved for implementations (i.e. underscore-names),
or else the extra stuff must be protected by a conditional using a name
in the implementation's reserved name space (as in your example).  The
rationale for the latter usage is that an application, by defining a
symbol reserved for implementations, has entered the realm of "undefined
behavior", which permits an escape from the otherwise stringent ANSI C
constraints.

>I have always felt that the ANSI C position on namespace pollution was a
>little parochial.  Obviously, it is causing problems with other ongoing,
>and useful, standards such as IEEE 1003 (POSIX).

Excuse me, but as acting liaison between the two groups I must say that
I don't think 1003.1 ever quite understood this issue as well as X3J11.
Certainly the solution adopted by 1003.1 (_POSIX_SOURCE) doesn't properly
address the issue.  It is THAT, combined with the mess that constitutes
existing practice in this area, that is causing problems.  The name space
anti-pollution guarantee for portable programming is one I find quite
valuable.  In fact I don't see any viable alternative for specifying a
system-independent C standard.  I wish 1003.1 had done as well in the
specifications for their own headers..

Feel free to blame me for not doing a good enough job as liaison.

>I must be confused here, because I do not understand how an application
>can be both ANSI C conforming and P1003.1 conforming if it is attempting
>to use features which only are available in 1003.1.

Please read more carefully.  I said "implementation", not "application".

>If the application is using only those features available to ANSI C,
>then it would be able to #undef _POSIX_SOURCE, or just ignore
>_POSIX_SOURCE.

A strictly conforming ANSI C application cannot #undef _POSIX_SOURCE,
and in any event maximally-portable ANSI C programs are supposed to be
writable without reference to the POSIX standard.  The joint X3J11/P1003
goal is for such applications to work unchanged in a simultaneously
ANSI C and POSIX conforming implementation.

>... why should the application have to define it.  It should maybe
>test for it, if it going to optionally use 1003.1 facilities.

Because IEEE Std 1003.1 SAYS the application, not the implementation,
optionally defines _POSIX_SOURCE.

>I think that an application which is being developed for strict ANSI C
>environments on a P1003.1 conforming system should take additional steps, 
>such as #undef _POSIX_SOURCE, simply to make sure that the available
>extensions in 1003.1 are not used.

Sorry, that is not proper to require for portable use of a system-
independent programming language.  How would you feel if the Pascal
standard said "Portable programs must XXX in order to be sure that
they will work on VMS systems, and YYY to be sure they work on DOS,
and ..."?