From ajosey@rdg.opengroup.org Tue Jul 25 13:14:22 2000 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by dkuug.dk (8.9.2/8.9.2) with SMTP id NAA06136 for ; Tue, 25 Jul 2000 13:14:21 +0200 (CEST) (envelope-from ajosey@rdg.opengroup.org) Received: by mailgate.rdg.opengroup.org; id AA26940; Tue, 25 Jul 2000 11:21:53 GMT Received: from skye.rdg.opengroup.org [192.153.166.247] by smtp.opengroup.org via smtpd V1.36 (00/03/29 11:54:16) for ; Tue Jul 25 12:21 BST 2000 Received: (from ajosey@localhost) by skye.rdg.opengroup.org (8.9.3/8.8.7) id MAA03016; Tue, 25 Jul 2000 12:14:15 +0100 Date: Tue, 25 Jul 2000 12:14:15 +0100 From: Andrew Josey Message-Id: <1000725111415.ZM3015@skye.rdg.opengroup.org> Reply-To: ajosey@rdg.opengroup.org (Andrew Josey) X-Mailer: Z-Mail (5.0.0 30July97) To: ajosey@opengroup.org Subject: Finalised PASC 1003.1 Interpretations #102-104,106-108 Cc: stds-pasc-ieee-officers@ieee.org, sc22wg15@dkuug.dk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Andrew Josey From: Andrew Josey, PASC Interpretations Functional Chair Reference: PASC 1003.1 #102-104, 106-108 Dear Mr. Josey Subject: IEEE Standard 1003.1 Enclosed is the official response for your request for an interpretation of IEEE Standard 1003.1. This response was developed and approved by the members of the 1003.1 Interpretations Committee. To obtain an understanding of the PASC Guidelines for interpretations and their classifications please read http://www.pasc.org/interps/ Please can you confirm receipt of this electronic mail message within ten working days, please carbon copy your response to the IEEE (stds-pasc-ieee-officers@ieee.org) Sincerely, Andrew Josey PASC Functional Chair Interpretations Enclosures Cc: IEEE PASC Officers, SC22 WG15 _____________________________________________________________________________ Notice: This is an unapproved draft PASC interpretation. Use at your own risk. Please direct any questions to a.josey@pasc.org _____________________________________________________________________________ PASC Interpretation reference 1003.1d-99 #102 _____________________________________________________________________________ Interpretation Number: XXXX Topic: posix_madvise Relevant Sections: 2.7.3 PASC Interpretation Request: ---------------------------- From: Andrew Josey Date: 2000 May 18 Address details: The Open Group ------------------------------------------------------------------------ 7 Defect Report concerning (number and title of International Standard or DIS final text, if applicable): Advanced Realtime Extensions: IEEE Std 1003.1d-1999 ------------------------------------------------------------------------ 8 Qualifier (e.g. error, omission, clarification required): 1 Error=1 , Omission=2, Clarification=3 ------------------------------------------------------------------------ 9 References in document (e.g. page, clause, figure, and/or table numbers): 2.7.3 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): 1003.1d, Section 2.7.3 clearly states that posix_madvise() is to be declared in , and no mention in that section is made of .Yet in 20.2.1.1, the Synopsis states that the function is declared in . ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): change to ------------------------------------------------------------------------ Interpretation response ------------------------ The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale ------------- This is an ambiguity in the 1003.1d standard as approved and interpretations must favor the looser conformance requirement, in this case allowing either header. Notes to project editor(not part of this interpretation): -------------------------------------------------------- The entry for posix_madvise() in the header (clause 2.7.3) is in error. posix_madvise() should be included in and not , please correct in the revision. Forwarded to Interpretations group: 21 May 2000 Proposed resolution: 28 May 2000 Finalised Interpretation: 25 July 2000 _____________________________________________________________________________ Notice: This is an unapproved draft PASC interpretation. Use at your own risk. Please direct any questions to a.josey@pasc.org _____________________________________________________________________________ PASC Interpretation reference 1003.1d-99 #103 _____________________________________________________________________________ Interpretation Number: XXXX Topic: posix_spawn Relevant Sections: 3.1.6 PASC Interpretation Request: ---------------------------- From: Andrew Josey Date: 2000 May 18 Address details: The Open Group ------------------------------------------------------------------------ 7 Defect Report concerning (number and title of International Standard or DIS final text, if applicable): Advanced Realtime Extensions: IEEE Std 1003.1d-1999 ------------------------------------------------------------------------ 8 Qualifier (e.g. error, omission, clarification required): 2 Error=1 , Omission=2, Clarification=3 ------------------------------------------------------------------------ 9 References in document (e.g. page, clause, figure, and/or table numbers): 3.1.6 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): 1003.1d, Section 3.1.6.2 (d14,p22,l368-370) omits to say when the change of default signal behavior takes place. ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): Add to step 2, after signal mask, "signal default actions" ------------------------------------------------------------------------ Interpretation response ------------------------ The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale ------------- This appears to be an omission. Notes to project editor (not part of this interpretation): ---------------------------------------------------------- The 1003.1 revision should accept the solution proposed in section 11 above. Forwarded to Interpretations group: 21 May 2000 Proposed resolution: 28 May 2000 Finalised Interpretation: 25 July 2000 _____________________________________________________________________________ Notice: This is an unapproved draft PASC interpretation. Use at your own risk. Please direct any questions to a.josey@pasc.org _____________________________________________________________________________ PASC Interpretation reference 1003.1d-99 #104 _____________________________________________________________________________ Interpretation Number: XXXX Topic: EBADF Relevant Sections: 3.1.4.4 PASC Interpretation Request: ---------------------------- From: Andrew Josey Date: 2000 May 18 Address details: The Open Group ------------------------------------------------------------------------ 7 Defect Report concerning (number and title of International Standard or DIS final text, if applicable): Advanced Realtime Extensions: IEEE Std 1003.1d-1999 ------------------------------------------------------------------------ 8 Qualifier (e.g. error, omission, clarification required): 2 Error=1 , Omission=2, Clarification=3 ------------------------------------------------------------------------ 9 References in document (e.g. page, clause, figure, and/or table numbers): 3.1.4.4 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): 1003.1d, Section 3.1.4.4 (d14,p16,l117) EBADF currently states that this applies to "fildes". It is most probably true for "newfildes". ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): Add "or newfildes" after "fildes" ------------------------------------------------------------------------ Interpretation response ------------------------ The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale ------------- None. Notes to project editor (not part of this interpretation): ---------------------------------------------------------- For posix_spawn_file_actions_adddup2(), the EBADF case should be extended to include "newfildes" as noted in section 11 above. Forwarded to Interpretations group: 21 May 2000 Proposed resolution: 28 May 2000 Finalised Interpretation: 25 July 2000 _____________________________________________________________________________ Notice: This is an unapproved draft PASC interpretation. Use at your own risk. Please direct any questions to a.josey@pasc.org _____________________________________________________________________________ PASC Interpretation reference 1003.1d-99 #106 _____________________________________________________________________________ Interpretation Number: XXXX Topic: reinitializing an initialized spawn attributes object. Relevant Sections: 3.1.5.2 PASC Interpretation Request: ---------------------------- From: Andrew Josey Date: 2000 May 18 Address details: The Open Group ------------------------------------------------------------------------ 7 Defect Report concerning (number and title of International Standard or DIS final text, if applicable): Advanced Realtime Extensions: IEEE Std 1003.1d-1999 ------------------------------------------------------------------------ 8 Qualifier (e.g. error, omission, clarification required): 1 Error=1 , Omission=2, Clarification=3 ------------------------------------------------------------------------ 9 References in document (e.g. page, clause, figure, and/or table numbers): 3.1.5.2 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): 1003.1d, Section 3.1.5.2 is not clear whether its permissible to reinitialize an already initialized spawn attributes object. It would seem clear from the presence of the destroy operation that such an action should result in undefined behavior but needs stating here. ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): Add "The effect of initializing an already initialized spawn attributes object is undefined" (after d14,p18,l175) ------------------------------------------------------------------------ Interpretation response ------------------------ The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale ------------- This is an unaddressed issue, its recommended this be addressed in the 1003.1 revision. Notes to project editor (not part of this interpretation): --------------------------------------------------------- Apply the solution noted in section 11 for the 1003.1 revision. Forwarded to Interpretations group: 21 May 2000 Proposed resolution: 28 May 2000 Finalised Interpretation: 25 July 2000 _____________________________________________________________________________ Notice: This is an unapproved draft PASC interpretation. Use at your own risk. Please direct any questions to a.josey@pasc.org _____________________________________________________________________________ PASC Interpretation reference 1003.1d-99 #107 _____________________________________________________________________________ Interpretation Number: XXXX Topic: pthread_attr_init Relevant Sections: 16.2.1.2 PASC Interpretation Request: ---------------------------- From: Andrew Josey Date: 2000 May 18 Address details: The Open Group ------------------------------------------------------------------------ 7 Defect Report concerning (number and title of International Standard or DIS final text, if applicable): Threads Extensions: IEEE Std 1003.1c-1995 ------------------------------------------------------------------------ 8 Qualifier (e.g. error, omission, clarification required): 1 Error=1 , Omission=2, Clarification=3 ------------------------------------------------------------------------ 9 References in document (e.g. page, clause, figure, and/or table numbers): 16.2.1.2, page 334, pthread_attr_init ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): 1003.1-1996, Section 16.2.1.2 is not clear whether its permissible to reinitialize an already initialized thread attributes object. It would seem clear from the presence of the destroy operation that such an action should result in undefined behavior but needs stating here. ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): Add "The effect of initializing an already initialized thread attributes object is undefined" (after line 38, page 334) ------------------------------------------------------------------------ Interpretation response ------------------------ The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale ------------- This is an unaddressed issue, which is recommended be addressed in the 1003.1 revision. Notes to the project editor (not part of this interpretation): --------------------------------------------------------------- Apply the change proposed in section 11 to the 1003.1 revision. Forwarded to Interpretations group: 21 May 2000 Proposed resolution: 28 May 2000 Finalised Interpretation: 25 July 2000 _____________________________________________________________________________ Notice: This is an unapproved draft PASC interpretation. Use at your own risk. Please direct any questions to a.josey@pasc.org _____________________________________________________________________________ PASC Interpretation reference 1003.1d-99 #108 _____________________________________________________________________________ Interpretation Number: XXXX Topic: timespec type in sched_param Relevant Sections: 13.1 PASC Interpretation Request: ---------------------------- From: Andrew Josey Date: 2000 Jun 2 Address details: The Open Group ------------------------------------------------------------------------ 7 Defect Report concerning (number and title of International Standard or DIS final text, if applicable): Advanced Realtime Extensions: IEEE Std 1003.1d-1999 ------------------------------------------------------------------------ 8 Qualifier (e.g. error, omission, clarification required): 1 Error=1 , Omission=2, Clarification=3 ------------------------------------------------------------------------ 9 References in document (e.g. page, clause, figure, and/or table numbers): 13.1, page 39 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): The description of the sched_ss_repl_period and sched_ss_init_budget members of the sched_param structure are defined as type "timespec". This should be "struct timespec" ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): Change "timespec" to "struct timespec" for these two lines. Interpretation response ------------------------ The standards states that the sched_ss_repl_period and sched_ss_init_budget members of the sched_param structure should be of type timespec and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale ------------- The omission of "struct" prefix to timespec is an error. Notes to project editor (not part of the interpretation): ------------------------ This should be fixed as in section 11. Forwarded to Interpretations group: 2 June 2000 Proposed resolution: 2 June 2000 Finalised Interpretation: 25 July 2000