These are additional comments on JTC 1.22.21.04.01.01 N2678 PDAM 7 to IS9945-1. This work is based on the backwards compatibility study that I am in progress of doing. Comments on P1003.1j/D6 Dated November 1997 Comments prepared July 1998 Submitter: Andrew Josey ---------------------------------------------------------------------- @ Page 5 Line 80-94 Section 2.5 Primitive System Data Types objection Problem: We need to make it clear that these additional primitive data types need only be provided if the appropriate option is supported - without this an implementation would have to add these types , even if it does not want to support the option, and thus existing conforming implementation will be made non-conformant when this amendment is approved. Action: Add into clause 2.5 after POSIX.1-1996 line 962: "Support for some primitive data types is dependent on implementation options. Where an implementation option is not supported the primitive data types for that option need not be found in the header ." Add into clause 2.5 after POSIX.1-1996 line 972 after the new types have been added. "An implementation need not provide the types pthread_barrier_t and pthread_barrierattr_t unless the _POSIX_BARRIERS implementation option is supported. An implementation need not provide the types pthread_rwlock_t and pthread_rwlockattr_t unless the _POSIX_READER_WRITER_LOCKS implementation option is supported. An implementation need not provide the type pthread_spinlock_t unless the _POSIX_SPINLOCKS implementation option is supported." Add a new table into POSIX.-1996 after line 996 with the title "Optional Primitive System Data Types" Take the table in D7 lines 87-94, add a column, titled "Implementation Option" to denote which option needs to be supported for an implementation to provide the type. Defined Type Description Implementation Option pthread_barrier_t ........ _POSIX_BARRIERS etc.... ---------------------------------------------------------------------- @ Page 7 Line 112 Section 2.7.2 POSIX.1 Symbols objection Problem: Changing the value of _POSIX_C_SOURCE will make existing implementations of POSIX.1 non conforming once this amendment is approved. Flagging versions and presence of options has to be done using additional feature test macros not by modifying existing feature test macros if we are going to achieve backwards compatibility. One proposal would be to have a specific feature test macro to denote support of a complete amendment, for example #define POSIX_AMENDMENT_J There's an argument that this goes against the style of previous amendments to date, and that is true, however the policy of amendments to date has been part of the problem, and doing it this way will partly achieve the goal of preserving backwards compatibility. Action: Delete the proposed amendment to this clause. ---------------------------------------------------------------------- @ Page 7 Line 128-149 Section 2.7.3 Headers and Function Prototypes objection Problem: Section 2.7.3 needs to be amended to denote the optionality of certain features being present. Without this existing implementations of POSIX.1 will be deemed non-conformant once this amendment is approved. It could be argued that this goes against the style of the existing POSIX.1 specification and yes this is true - yet the existing style is the problem we are seeing with the inability to preserve backwards compatibility. Action: Change clause 2.7.3 , POSIX.1-1996 line 146 "prototypes or declarations shall appear in the headers listed below. Presence of some prototypes or declarations is dependent on implementation options. Where an implementation option is not supported the prototype or declaration need not be found in the header." (also consider whether we need to fully enumerate this per the exact functions). ---------------------------------------------------------------------- @ Page 8 Line 174-177 Section 2.9.2 objection Problem: Changing the value of _POSIX_VERSION will make existing implementations of POSIX.1 non conforming once this amendment is approved. Flagging versions and presence of options has to be done using additional feature test macros not by modifying existing feature test macros if we are going to achieve backwards compatibility. There's an argument that this goes against the style of previous amendments to date, and that is true, however the policy of amendments to date has been part of the problem, and doing it this way will partly achieve the goal of preserving backwards compatibility. Action: Delete the proposed amendment to this clause. ---------------------------------------------------------------------- @ Page 13 Line 2 Section 4.8.1 objection Problem: We need to make it clear that these additional configuration system variables need only be provided if the appropriate option is supported - without this an implementation would have to be modified to stay in conformance , even if it does not want to support the option and thus existing conforming implementation will be made non-conformant when this amendment is approved. The new options should be in a separate table to 4-2, since 4-2 has the mandatory options that we've all agreed to support to date. Action: Add after the clause 4.1.8.2 after POSIX.1-1996 line 426: "Support for some configuration numbers is dependent on implementation options (see table 4-3). Where an implementation option is not supported the variable need not be supported. " ---------------------------------------------------------------------- @ Page 24 Line 31-34 Section 13.2 objection Problem: In the synopsis we need to make it clear that these functions are optional - that implementations need not supply the header or the function prototypes if they do not support the option- and that programmers should be aware of the appropriate feature test macro to test for support. Without this application programs could fail to compile. There's an argument that this goes against the style of previous amendments to date, and that is true, however the stubs policy of amendments to date has been part of the problem, and doing it this way will achieve the goal of preserving backwards compatibility. Leaving the synopsis as is gives the incorrect impression that implementations provide stubs allowing code to compile. Action: Change the function synopses as follows: #include #ifdef _POSIX_MONOTONIC_CLOCK #include int pthread_condattr_getclock .... int pthread_condattr_setclock .... #endif In 11.5.1.1/11.5.2.1/11.5.3.1 #include #ifdef _POSIX_BARRIERS .... #endif In 11.6.1.1/11.6.2.1/11.6.3.1/11.6.4.1/11.6.5.1 #include #ifdef _POSIX_READER_WRITER_LOCKS .... #endif In 11.7.1.1/11.7.2.1/11.7.3.1 #include #ifdef _POSIX_SPINLOCKS .... #endif In 12.4.2.1/12.4.3.1/12.4.4.1 #include #ifdef _POSIX_TYPED_MEMORY_OBJECTS .... #endif In 14.2.6.1/ #include #ifdef _POSIX_CLOCK_NANOSLEEP .... #endif ------------------------------END OF COMMENTS--------------------------------