jms@apple.com (John Michael Sovereign) (07/12/90)
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
karish@mindcrf.uucp (07/14/90)
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
gwyn@smoke.brl.mil (Doug Gwyn) (07/15/90)
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