🚀 go-pugleaf

From:  jms@apple.com (John Michael Sovereign)


In article <9951@cs.utexas.edu> jason@cnd.hp.com (Jason Zions) writes:

> This makes the assumption that there is indeed a single POSIX name space,
> to which pieces are added by the various working groups. This assumption,
> while a reasonable one, is in fact not correct.

There is, however, a single C language name space which new standards (and 
revisions)
pollute as long as they continue to use header files already defined by 
ANSI C and/or POSIX.1
(as I believe Doug Gwyn pointed out recently).

> The various 1003.* working groups are *not* developing separate 
components
> of an overall, integrated POSIX standard. Each POSIX standard stands 
alone....

>From what I've heard, there HAS been discussion at the ISO level of 
bundling the C language
interfaces of POSIX.2 and/or POSIX.4 into future versions of 9945-1.  
Unfortunately, a decision on this matter might be delayed until after the 
IEEE standards have been adopted....

As far as _POSIX_1_SOURCE goes, it's not clear to me why the existing 
_POSIX_SOURCE
can't be used (perhaps modified) for this purpose.

John Sovereign
jms@apple.com
"Perhaps software developers should face the same legal support 
requirements as parents."


Volume-Number: Volume 20, Number 121

From:  Doug Gwyn <gwyn@smoke.brl.mil>


In article <9951@cs.utexas.edu> std-unix@uunet.uu.net writes:
>From:  Jason Zions <jason@cnd.hp.com>
>Worse yet, it appears that one of the POSIX Real Time Profiles may very
>well require only a subset of 1003.1; how on earth does one represent
>*that* using the _POSIX_C_SOURCE scheme?

Shouldn't 1003.0 step in here and exert some coordination?
1003.1 was deliberately not split into "levels" a la COBOL,
and we meant it.  A Real-Time extension could very well exist
(say, number 1003.123a) and not require that 1003.1 be specified,
but be useless in the absence of some subset of 1003.1 or equivalent,
just as a hosted C implementation on UNIX does not specify that
open() exist, but secretly requires a function with similar
properties in order to be implemented at all.  If the problem is
that the extension wants to contradict some of 1003.1, then it is
an INCOMPATIBLE standard (i.e. one could not specify simultaneous
conformance with 1003.1 and 1003.123a), and I thought that standards
organizations prohibited that.


Volume-Number: Volume 20, Number 126

From:  karish@mindcrf.uucp


In article <9997@cs.utexas.edu> std-unix@uunet.uu.net writes:
>From:  jms@apple.com (John Michael Sovereign)
>In article <9951@cs.utexas.edu> jason@cnd.hp.com (Jason Zions) writes:
>
>> This makes the assumption that there is indeed a single POSIX name space,
>> to which pieces are added by the various working groups. This assumption,
>> while a reasonable one, is in fact not correct.
>
>There is, however, a single C language name space which new standards (and 
>revisions)
>pollute as long as they continue to use header files already defined by 
>ANSI C and/or POSIX.1
>(as I believe Doug Gwyn pointed out recently).

>From the 1003.1 standard, 2.8.2:

    Symbols called `feature test macros' are used to control the
    visibility of symbols that might be included in a header.
    Implementations, future versions of this standard, and other
    standards may define additional feature test macros.

My interpretation of this text is that the 1003.1 committee wanted to
provide a mechanism by which a number of standards and implementations
could share the C namespace.  Of course, extended use of this mechanism
is up to the other standards committees and implementors, and is
outside the scope of 1003.1.  Perhaps this is an issue that Dot 0
could help clear up.

>> The various 1003.* working groups are *not* developing separate 
>components
>> of an overall, integrated POSIX standard. Each POSIX standard stands 
>alone....

Which makes it essential that each standard specify what it assumes
is available from its host, and what it will add to the composite
environment.  While each standard may stand alone, implementations
certainly won't.

>As far as _POSIX_1_SOURCE goes, it's not clear to me why the existing 
>_POSIX_SOURCE
>can't be used (perhaps modified) for this purpose.

Because, unlike __STDC__, _POSIX_SOURCE is #defined or not #defined;
its value is not significant.  The implication of the suggestion to use
_POSIX_1_SOURCE for 1003.1a-conforming headers is that the 1003.1
committee is reserving for its own use all feature test macro names
that start with _POSIX_.  This means that the 1003.2 committee will be
on shaky ground if they require that programmers #define
_POSIX_2_SOURCE in order to make 1003.2 symbols visible.

The approach chosen by the ANSI C committee was a good one:  Use a single
name for the feature test macro, and change the macro's VALUE when a
new version of the standard supersedes an old one.
-- 

	Chuck Karish		karish@mindcraft.com
	Mindcraft, Inc.		(415) 323-9000		


Volume-Number: Volume 20, Number 124

From:  Doug Gwyn <gwyn@smoke.brl.mil>


In article <10059@cs.utexas.edu> std-unix@uunet.uu.net writes:
>>From the 1003.1 standard, 2.8.2:
>    Symbols called `feature test macros' are used to control the
>    visibility of symbols that might be included in a header.
>    Implementations, future versions of this standard, and other
>    standards may define additional feature test macros.
>My interpretation of this text is that the 1003.1 committee wanted to
>provide a mechanism by which a number of standards and implementations
>could share the C namespace.

The feature-test macro provision was the outcome of discussions among
DOnn Terry, Dave Prosser, myself, and a few others in an attempt to
resolve the problem that a single implementation could not simultaneously
conform to IEEE Std 1003.1 and ANS X3.159 due to the strict prohibition
of the latter against implementations defining or declaring non-reserved
identifiers in the standard headers.  Because of the evolutionary history
of the standard headers, some of them contained both UNIX-specific and
OS-independent definitions/declarations; for example, <stdio.h> included
fopen(), which applies in every hosted C environment, and fdopen(), which
is relevant only for UNIX-like environments.  Partly out of legitimate
political concerns, X3J11 refused to allow any special dispensation for
UNIX-specific extensions in the standard C headers, and as a generally
appreciated service to C programmers everywhere forbid conforming C
implementations to add other (non-reserved, i.e. not starting with
underscore etc.) identifiers to the standard headers.  Thus, in effect
other standards such as POSIX, if they are to be compatible with the C
language standard, must not require implementations to define/declare
such names in the headers specified in X3.159.  Yet, P1003 wished to add
some of the traditional UNIX identifiers to those headers.  This is the
problem that the feature-test macro POSIX_SOURCE was intended to solve.
(X3J11 recommended a similar but functionally different solution.)  While
they were at it, P1003 decided that packages other than 1003.1 might also
benefit from feature-test macros, and ended up with the wording you saw.

The technical loophole is that any application that defines _POSIX_SOURCE
has violated a constraint of X3.159, by using a reserved identifier, and
this allows the implementation to act in a non-X3.159-conforming manner,
in this case to define/declare otherwise-prohibited identifiers.

One drawback is that any portable 1003.1-based application that uses any
of the 1003.1 extensions in standard headers will have to predefine the
feature-test macro before including the headers.

There is no such problem with inclusion of headers NOT specified in
X3.159.  Thus, feature-test macros can be avoided simply by specifying
that new facilities be defined/declared in new add-on headers.  This is
much more convenient for the programmer and is highly recommended.
There is no historical-evolutionary problem for new POSIX standards,
and thus there is no need for a mechanism to share the standard headers
for new standards.  Instead of trying to add more cruft to standard C
headers, new inventions should provide their own headers.


Volume-Number: Volume 20, Number 131