Comments on P1003.1d/D11 Dated May 1998 Comments prepared July 1998 Submitter: Andrew Josey ---------------------------------------------------------------------- @ Page 8 Line 104-105 Section 2.4 Error Numbers objection Problem: We need to make it clear that these additional error numbers need only be provided if the appropriate option is supported - without this an implementation would have to add the symbolic value for the error number, even if it does not want to support the option. Action: Add into clause 2.4 after POSIX.1-1996 line 786: "Support for some error numbers is dependent on implementation options. Where an implementation option is not supported the symbolic name for that error number need not be found in the header ." The optional errors need to be broken out into a section at the end of 2.4, for example for this draft amendment: "If the .... option is supported, then the following symbolic names for error numbers are provided: [EDISABLED] ...... Otherwise: Either the implementation shall support the symbolic names as described above, or they shall not be provided." ---------------------------------------------------------------------- @ Page 8 Line 110-112 Section 2.7.2 POSIX.1 Symbols objection Problem: The requirement on lines 110-112 imposes restrictions on existing implementations of POSIX.1 that will make them nonconforming once this amendment is approved. Action: Delete the proposed amendment to section 2.7.2. ---------------------------------------------------------------------- @ Page 9 Line 119 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_D Action: Delete the proposed amendment to this clause. ---------------------------------------------------------------------- @ Page 9 Line 136-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 11 Line 179 Section 2.8.5 objection Problem: Why does ALLOC_SIZE_MIN not have a POSIX_ prefix? Action: Change "ALLOC_SIZE_MIN" to "POSIX_ALLOC_SIZE_MIN" ---------------------------------------------------------------------- @ Page 12 Line 211 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. Action: Delete the proposed amendment to this clause. ---------------------------------------------------------------------- @ Page 14 Section 3.1.4.1 Spawn a Process 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. Action: Change the function synopsis to as follows: #include #ifdef _POSIX_SPAWN #include int posix_spawn .... etc ... #endif This also applies to 11.2.6.1, 11.3.1.1, 11.3.3.1, 15.2.4.1, 15.2.5.1, 20.2.1.1, 20.2.2.1, 20.2.3.1, 21.1.1.1, 21.1.2.1, 21.1.2.5, ---------------------------------------------------------------------- @ Page 20 Section 3.2.1.2 Wait for Process Termination objection Problem: The additional macros need to be conditional on the support of the implementation option. Action: Add after POSIX.1-1996 section 3.2.1.2 line 405 "If the Spawn option is supported, then the following macros are provided: WIFSPAWNFAIL(stat_val) .... WSPAWNERRNO(stat_val) .... Otherwise: Either the implementation shall support the macros as described above, or they shall not be provided." ---------------------------------------------------------------------- @ Page 31 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. 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 36 Line 44-45 Section 11.2.6.4 objection Problem: Adding sem_timedwait() to the existing error clauses , will make a previously existing implementation of POSIX.1 nonconforming since the error clauses require an ENOSYS stub. 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. Action: The addition of sem_timedwait() needs to allow the case where the implementation does not provide the function, so change the Otherwise clause as follows: " Otherwise: Either the implementation shall support the function as described above, or the function shall not be provided." ---------------------------------------------------------------------- @ Page 43 Line 16-17 Section 13.2 objection Problem: We need to make it clear that the additional scheduling policy 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. Action: Add to POSIX.1-1996 P288 Clause 13.2 line 46: "If the Process Sporadic Server or the Thread Sporadic Server option is supported, then the following scheduling policy is provided in : SCHED_SPORADIC ..... " ---------------------------------------------------------------------- @ Page 60 Line 50-51 Section 15.2.4.4 objection Problem: Its not possible to ballot on these lines as the proposed amendment is not specific. Action: Enumerate the proposed amendment. ---------------------------------------------------------------------- @ Page 60 Line 59 Section 15.2.4.4 objection Problem: Given the text on lines 42-43 the addition of an ENOSYS is not needed . Action: Delete the proposed amendment ---------------------------------------------------------------------- @ Page 62 Line 124 Section 15.2.4.4 objection Problem: Given the text on line 107 the addition of an ENOSYS is not needed . Action: Delete the proposed amendment ------------------------------END OF COMMENTS--------------------------------