X/Open (The Open Group) Institutional Ballot +44 118 950 8311 x2250 ajosey@rdg.opengroup.org Fax: +44 118 950 0110 P1003.1q/D3 ---------------------------------------------------------------------------- @ 2.4 o 1 1 Sect 2.4 OBJECTION. page 6 line 120-124 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: [EENDOFDATA] ...... Otherwise: Either the implementation shall support the symbolic names as described above, or they shall not be provided." ---------------------------------------------------------------------- @ 2.7.3 o 2 2 Sect 2.7.3 OBJECTION. page 7, line 127-163 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 129-130 as follows: If the Threads option and the Trace option are supported: pthread_attr_gettracingstate(), .... pthread_settracingstate() If the Trace option is supported: posix_trace_attr_destroy() .... posix_trace_userevent() ---------------------------------------------------------------------- @ 2.8.2 o 3 3 Sect 2.8.2 OBJECTION. page 8, Line 168-167 Problem: An amendment should not add values unconditionally to section 2.8.2, since doing so will require a conforming system to add the values to remain in conformance, even if it does not support the implementation option. Action: The following change is recommended to POSIX.1-1996 Clause 2.8.2 after line 1371: "Support for some minimum values is dependent on implementation options. Where an implementation option is not supported the minimum value or values associated with that option need not be found in the header ." The new minimum values (in lines 168 thru 188) should be added in a separate table with the title "Table 2-3a - Optional Minimum Values". This table should have the same format as per table 2-3 with an additional column to denote the implementation option associated with the minimum value. ---------------------------------------------------------------------- @ 2.8.4 o 4 4 Sect 2.8.4 OBJECTION. page 9, Line 192-215 Problem: An amendment should not add values unconditionally to section 2.8.4, since doing so will reqire a conforming system to add the values even if it does not support the implementation option. Action: The following change is recommended to POSIX.1-1996 Clause 2.8.4 after line 1444: "Support for the run-time invariant values in Table 2-5a is dependent on implementation options. Where an implementation option is not supported the run-time invariant value or values associated with that option need not be found in the header , and need not be supported by the sysconf() function. " The new run-time invariant values should be added in a separate table with the title "Table 2-5a - Optional Run-Time Invariant Values". This table should have the same format as per table 2-5 with an additional column to denote the implementation option associated with the value. ---------------------------------------------------------------------- @ 2.9.3 o 5 5 Sect 2.9.3 OBJECTION. page 10, Line 220-233 Problem: Flagging versions and presence of options should include the value of the year 1999ymmL (or 200ymmL) in the value of the 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 yyyymmL 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: Expand the entries in table 2-10 "Compile-Time Symbolic Constants" L220-233 to also include Feature Test macros so the wording for each reads on lines 222, 225, 228 and 231: If this symbol is defined to the value yyyymmL, the implementation supports the .... ---------------------------------------------------------------------- @ 24.1 c 6 6 Sect 24.1 COMMENT. page 17, lines 2-9 Problem: In many places the description explicitly calls out a process or processes. Should this really be a thread or threads? Action: Consider rewording "process" to "thread" ---------------------------------------------------------------------- @ 24.3.2.1 o 7 7 Sect. 24.3.2.1 OBJECTION. page 25, line 296 Problem: Section 24.2.1 defines these types in , therefore there is no need to include Action: Delete #include (line 296) ---------------------------------------------------------------------- @ 24.3.3.1 o 8 8 Sect. 24.3.3.1 OBJECTION. page 27, line 348-349 Problem: Section 24.2.1 defines the trace types in , therefore there is no need to include These functions do use struct utsname, and struct timespec without a corresponding #include. Action: Delete #include (line 348) EITHER Split out posix_trace_attr_getutsname () so that it has two #includes for it: #include #include Split out posix_trace_attr_getcreatetime(), and posix_trace_attr_getclockres() so that they have two includes: #include #include OR in section 24.2.1 in the description of add after line 53: Inclusion of the header may make visible the symbols allowed by this part of ISO/IEC 9945 to be in the headers and . ---------------------------------------------------------------------- @ 24.3.4.1 o 9 9 Sect. 24.3.4.1 OBJECTION. page 29, line 430 Problem: Section 24.2.1 defines the trace types in , therefore there is no need to include Action: Delete #include (line 430) ---------------------------------------------------------------------- @ 24.3.6.1 o 10 9 Sect. 24.3.6.1 OBJECTION. page 35, line 653 Problem: The type pthread_attr_t is defined in See PASC Interpretation Ref: pasc-1003.1c-46 . Action: Add #include (line 653) ---------------------------------------------------------------------- @ 24.3.9.1 o 11 11 Sect. 24.3.9.1 OBJECTION. page 41, line 875 Problem: Section 24.2.1 defines the trace types in , therefore there is no need to include Action: Delete #include (line 875) ---------------------------------------------------------------------- @ 24.3.10.1 o 12 12 Sect. 24.3.10.1 OBJECTION. page 44, line 990 Problem: Section 24.2.1 defines the trace types in , therefore there is no need to include Action: Delete #include (line 990) ---------------------------------------------------------------------- @ 24.3.11.1 o 13 13 Sect. 24.3.11.1 OBJECTION. page 45, line 1040 Problem: Section 24.2.1 defines the trace types in , therefore there is no need to include Action: Delete #include (line 1040) ---------------------------------------------------------------------- @ 24.3.12.1 o 14 14 Sect. 24.3.12.1 OBJECTION. page 47, line 1113 Problem: Section 24.2.1 defines the trace types in , therefore there is no need to include Action: Delete #include (line 1113) ---------------------------------------------------------------------- @ 24.3.13.1 o 15 15 Sect. 24.3.13.1 OBJECTION. page 49, line 1165 Problem: Section 24.2.1 defines the trace types in , therefore there is no need to include Action: Delete #include (line 1165) ---------------------------------------------------------------------- @ 24.3.14.1 o 16 16 Sect. 24.3.14.1 OBJECTION. page 50, line 1205 Problem: The type pthread_t is defined in See PASC Interpretation Ref: pasc-1003.1c-46 . Action: Add #include (line 653) ---------------------------------------------------------------------- @ 24.3.16.1 o 17 17 Sect. 24.3.16.1 OBJECTION. page 54, line 1339 Problem: Section 24.2.1 defines the trace types in , therefore there is no need to include Action: Delete #include (line 1339) ---------------------------------------------------------------------- @ 24.3.17.1 o 18 18 Sect. 24.3.17.1 OBJECTION. page 55, line 1396 Problem: Section 24.2.1 defines the trace types in , therefore there is no need to include Action: Delete #include (line 1396) ---------------------------------------------------------------------- ----- 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.