X/Open (The Open Group) Institutional Ballot +44 118 950 8311 x2250 P1 of 8 ajosey@rdg.opengroup.org Fax: +44 118 950 0110 P1003.1d/D11 ---------------------------------------------------------------------- @ 0 o 1 1 Sect. 0 OBJECTION. page 0, line 0 Problem: POSIX.1-1996 specifies that the prefixes sem_, pthread_ and mq_ are reserved for implementation use. There may be implementations that have used these names. This draft includes new functions using these previously reserved prefixes. Action: Change the new functions so that the prefixes start with posix_ Also change POSIX.1-1996 Section 2.7.2 lines 1119-1120 from: "Future revisions of this part of ISO/IEC 9945, and other POSIX standards, are likely to use symbols in these same reserved spaces." to "Future revisions of this part of ISO/IEC 9945 shall use the reserved prefixes posix_ , _POSIX_ and POSIX_ for additions into the reserved space." ---------------------------------------------------------------------- @ 2.4 o 2 2 Sect 2.4 OBJECTION. page 8 line 104-105 Problem: (additional error numbers) 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." ---------------------------------------------------------------------- X/Open (The Open Group) Institutional Ballot +44 118 950 8311 x2250 P2 of 8 ajosey@rdg.opengroup.org Fax: +44 118 950 0110 P1003.1d/D11 ---------------------------------------------------------------------- @ 2.7.2 o 3 3 Sect 2.7.2 OBJECTION. page 8, line 110-112 Problem: (new requirement on posix.1 symbols) 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. ---------------------------------------------------------------------- @ 2.7.2 o 4 4 Sect 2.7.2 OBJECTION. page 9 line 119 Problem: (change _POSIX_C_SOURCE) 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. Each of the Compile-Time Symbolic Constants in Table 2-10 should be defined with the value 199ymmL if that option is supported. That will allow an application not only to determine if the option is supported, but also determine if the implementation supports the version of that option corresponding to the version of the standard the user is referencing. Action: Delete the proposed amendment to this clause. Expand the entries in table 2-10 "Compile-Time Symbolic Constants" L194-207 to also include Feature Test macros. Add the value 199ymmL to each of the Compile-Time Symbolic Constants in Table 2-10. ---------------------------------------------------------------------- X/Open (The Open Group) Institutional Ballot +44 118 950 8311 x2250 P3 of 8 ajosey@rdg.opengroup.org Fax: +44 118 950 0110 P1003.1d/D11 ---------------------------------------------------------------------- @ 2.7.2 o 5 5 Sect 2.7.3 OBJECTION. page 9, line 136-149 Problem: (optional header contents) 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." Replace lines 138-149 as follows: If the Advisory Information option is supported: posix_fadvise(), posix_madvise(), posix_fallocate(), posix_ffree() If the Message Passing option and the Timeouts option is supported: mq_timedsend(), mq_timedreceive() If the Thread CPU-Time Clocks option is supported: pthread_attr_setcpuclkallow(), pthread_attr_getcpuclkallow(), pthread_getcpuclockid(), clock_getcpuclockid() If the Threads option and the Timeouts option is supported: pthread_mutex_timedlock(), pthread_mutexattr_gettimeoutallow(), pthread_mutexattr_settimeoutallow() If the Semaphores option and the Timeouts option is supported: sem_timedwait() If the Spawn option is supported: posix_spawn(), posix_spawnp() If the Advisory Information option is supported: posix_memalign() Note if objection 1 is accepted , several of the names above need to have "posix_" prepended to them (those in , , and ). ---------------------------------------------------------------------- X/Open (The Open Group) Institutional Ballot +44 118 950 8311 x2250 P4 of 8 ajosey@rdg.opengroup.org Fax: +44 118 950 0110 P1003.1d/D11 ---------------------------------------------------------------------- @ 2.8.4 o 6 6 Sect 2.8.4 OBJECTION. page 10, Line 164 Problem: Why does _SS_REPL_MAX not have a POSIX_ prefix? A POSIX_ prefix is required to meet the namespace requirements You will also need to change the Minimum Value to something different. Action: Change "_SS_REPL_MAX" to "_POSIX_SS_REPL_MAX" ---------------------------------------------------------------------- @ 2.8.5 o 7 7 Sect 2.8.5 OBJECTION. page 11, Line 179 Problem: Why does ALLOC_SIZE_MIN not have a POSIX_ prefix? A POSIX_ prefix is required to meet the namespace requirements Action: Change "ALLOC_SIZE_MIN" to "POSIX_ALLOC_SIZE_MIN" ---------------------------------------------------------------------- @ 2.8.5 o 8 8 Sect 2.8.5 OBJECTION. page 11, Line 175-187 Problem: The only references to the names in the first column appear here and in rationale, they are not used anywhere in the draft. Remove the changes to this section. Action: Delete these changes to section 2.8.5 ---------------------------------------------------------------------- X/Open (The Open Group) Institutional Ballot +44 118 950 8311 x2250 P5 of 8 ajosey@rdg.opengroup.org Fax: +44 118 950 0110 P1003.1d/D11 ---------------------------------------------------------------------- @ 2.9.2 o 9 9 Sect. 2.9.2 OBJECTION. page 12, line 211 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. ---------------------------------------------------------------------- @ 3.1.4.1 o 10 10 Sect. 3.1.4.1 OBJECTION. page 14, line 23 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 clauses 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, ---------------------------------------------------------------------- X/Open (The Open Group) Institutional Ballot +44 118 950 8311 x2250 P6 of 8 ajosey@rdg.opengroup.org Fax: +44 118 950 0110 P1003.1d/D11 ---------------------------------------------------------------------- @ 3.2.1.2 o 11 11 Sect. 3.2.1.2 OBJECTION. page 20, line 284-300 Problem: ( Wait for Process Termination ) It does not seem necessary or useful to have the wait system call distinguish between returns from process that were created by fork/exec and those created by spawn/spawnp. Action: Delete lines 284-300. It would be acceptable to add a note that a process that fails after a successful spawn/spawnp call can be detected using the existing wait macro WIFEXITED and the error code extracted using the existing wait macro WIFEXITCODE. ---------------------------------------------------------------------- @ 3.2.1.2 o 12 12 Sect. 3.2.1.2 OBJECTION. page 20, line 284-300 Problem: ( Wait for Process Termination ) If the previous objection is not accepted then: The additional macros need to be conditional on the support of the implementation option. Action: (Line numbers are given for POSIX.1-1996) 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." ---------------------------------------------------------------------- X/Open (The Open Group) Institutional Ballot +44 118 950 8311 x2250 P7 of 8 ajosey@rdg.opengroup.org Fax: +44 118 950 0110 P1003.1d/D11 ---------------------------------------------------------------------- @ 4.8.1 o 13 13 Sect 4.8.1 OBJECTION. page 31, Line 2 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. This new table should include an additional column naming the option that would require the corresponding name value to be required to be defined in . Action: (line numbers are for POSIX.1-1996) 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. " The table headings should be: Variable named Value Required Option ---------------------------------------------------------------------- @ 13.2 o 14 14 Sect. 13.2 OBJECTION. page 43, line 16-17 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: (Line numbers are per POSIX.1-1996) 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 ..... " ---------------------------------------------------------------------- X/Open (The Open Group) Institutional Ballot +44 118 950 8311 x2250 P8 of 8 ajosey@rdg.opengroup.org Fax: +44 118 950 0110 P1003.1d/D11 ---------------------------------------------------------------------- @ 15.2.4.4 o 15 15 Sect. 15.2.4.4 OBJECTION. page 60, line 59 Problem: Given the text on lines 42-43 the addition of an ENOSYS is not needed . Action: Delete the proposed amendment ---------------------------------------------------------------------- @ 15.2.5.4 o 16 16 Sect. 15.2.5.4 OBJECTION. page 62, line 124 Problem: Given the text on line 107 the addition of an ENOSYS is not needed . Action: Delete the proposed amendment ---------------------------------------------------------------------- @ 21.1.2.2 o 17 17 Section 21.1.2.2 OBJECTION. page 81 line 72 Problem: Restricting fallocate() from changing the file size prevents a libary implementation of fallocate() on most systems. There seems to be no fundamental need for this restriction, as the programmer wants bytes to be in the file in the specified range. Action: Replace line 72 with "If the offset + len is beyond the current file size then fallocate() shall adjust the file size to offset + len. ============= End of X/Open ( The Open Group) Institutional Ballot =========== ----- Andrew Josey The Open Group Base WG Chair Apex Plaza,Forbury Road, Email: a.josey@opengroup.org Reading,Berks.RG1 1AX,England Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110 OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group.