From ajosey@tamarix.rdg.opengroup.org Wed Feb 17 12:21:48 1999 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by dkuug.dk (8.8.7/8.8.7) with SMTP id MAA11739 for ; Wed, 17 Feb 1999 12:21:47 +0100 (CET) (envelope-from ajosey@tamarix.rdg.opengroup.org) Received: by mailgate.rdg.opengroup.org; id AA30266; Wed, 17 Feb 1999 11:22:47 GMT Received: from tamarix.rdg.opengroup.org [192.153.166.189] by mailgate.rdg.opengroup.org via smtpd V1.26 (98/11/23 13:59:56) for ; Wed Feb 17 11:22 GMT 1999 Received: (from ajosey@localhost) by tamarix.rdg.opengroup.org (8.8.7/8.8.7) id LAA03857; Wed, 17 Feb 1999 11:16:53 GMT Date: Wed, 17 Feb 1999 11:16:53 GMT From: Andrew Josey Message-Id: <990217111651.ZM3856@tamarix.rdg.opengroup.org> Reply-To: ajosey@rdg.opengroup.org (Andrew Josey) X-Mailer: Z-Mail (5.0.0 30July97) To: ogtgbase@opengroup.org Subject: Finalised PASC 1003.1 Interpretation #87, 89, 90, 91 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-96 #87, 89, 90, 91 Dear Mr. Josey Subject: IEEE Standard 1003.1-1996 Enclosed is the official response for your requests for interpretation of IEEE Standard 1003.1-1990. 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 _____________________________________________________________________________ PASC Interpretation reference 1003.1-96 #87 _____________________________________________________________________________ Interpretation Number: XXXX Topic: struct sched_param and sched_setscheduler Relevant Sections: 13.1, 13.3.3.1 PASC Interpretation Request: ---------------------------- From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Date: Tue Apr 14 14:12:00 BST 1998 ------------------------------------------------------------------------ 7 Defect Report concerning (number and title of International Standard or DIS final text, if applicable): IEEE Std 1003.1-1996 (incorporates 1003.1-1990, 1003.1b-1993, 1003.1c-1995, 1003.1i-1995) (ISO 9945-1:1996) ------------------------------------------------------------------------ 8 Qualifier (e.g. error, omission, clarification required): 3 Error=1 , Omission=2, Clarification=3 ------------------------------------------------------------------------ 9 References in document (e.g. page, clause, figure, and/or table numbers): p 293, clause 13.3.3.1 sched_setscheduler, page 287 clause 13.1 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): IEEE Std 1003.1-1996 contains a structure , struct sched_param with one defined member sched_priority. Consider the following code extract: #define _POSIX_C_SOURCE 199506L void mycode() { struct sched_param param1; int j; j = MINPRIO; /* MINPRIO is a valid priority */ /* Also assume below that pid and policy are valid below */ param1.sched_priority = j; if (sched_setscheduler(pid, policy, &param1) == -1) { /* branch 1 */ } else /* branch 2 */ } Q1. Is an implementation conforming, that returns -1 on a call to sched_setscheduler() (branch 1) due to the fact that it has implementation defined members of the struct sched_param that are not initialized? Section 13.1 has a section of text that states: "Implementations may add extensions as permitted by 1.3.1.1, item(2). Adding extensions to this structure, which may change the behavior of the application with respect to this standard when those fields are uninitialized, also requires that the extension be enabled as required by 1.3.1.1" Q2. Is this a requirement on the application or the implementation? Q3. Is it possible to write a strictly conforming POSIX.1 application using the sched_param structure? ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): Q1. Yes since a conforming implementation may have extended the sched_param structure Q2. The application writer is required to consult the system documentation and may have to add extra initialization code for the sched_param structure. Q3. Its not possible to write a strictly conforming POSIX.1 application that uses the sched_param structure. ------------------------------------------------------------------------ Interpretation: Q1: The standard is clear that this is not conforming. From 1.3.1.1, page 3 of 1003.1b-1993: The conformance document shall define an environment in which an application can be run with the behavior specified by the standard. In no case shall such an environment require modification of a Strictly Conforming POSIX.1 Application. Q2: This is a requirement on the implementation. Q3: Yes. The implementation must not allow semantics related to implementation-specific members of struct sched_param to affect the behavior of a Strictly Conforming POSIX.1 Application. Rationale: The standard way to provide a choice between a strictly conforming execution environment and one with extensions is to have the implementation ignore the extensions unless an implementation-defined feature test macro is #defined when the program is compiled. An implementation that returns -1 unless implementation- added structure members are initialized and that documents this as an error condition as specified in subclause 2.4 (page 28, lines 675-684 of POSIX.1b-1993) is not in conformance with the Standard. Such an implementation is also broken with respect to 1.3.1.1, as quoted in the Interpretation above, and broken with respect to the application developer's reasonable expectations. Forwarded to Interpretations group: 14 Apr 1998 Proposed Interpretation: 17 Jul 1998 Finalised: February 17 1999 _____________________________________________________________________________ PASC Interpretation reference 1003.1-96 #89 _____________________________________________________________________________ Interpretation Number: XXXX Topic: timer_settime Relevant Sections: Page 315, clause 14.2.4 PASC Interpretation Request: ---------------------------- Date: Sun, 3 May 1998 02:43:27 -0500 ------------------------------------------------------------------------ 7 Defect Report concerning (number and title of International Standard or DIS final text, if applicable): IEEE Std 1003.1-1996 (incorporates 1003.1-1990, 1003.1b-1993, 1003.1c-1995, 1003.1i-1995) (ISO 9945-1:1996) ------------------------------------------------------------------------ 8 Qualifier (e.g. error, omission, clarification required): 3 Error=1 , Omission=2, Clarification=3 ------------------------------------------------------------------------ 9 References in document (e.g. page, clause, figure, and/or table numbers): Page 315, clause 14.2.4 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): The timer_settime() specificiation states: "If any of the following errors occur...." [EINVAL]A value structure specified a nanosecond value less than zero or greater than or equal to 1000 million." The spec also states: "If the it_value member of value is zero, the timer is disarmed. The effect of disarming or resetting a timer on pending expiration notifications is unspecified. " If I call timer_settime() with value->it_interval less than zero and greater than or equal to 100 million, and the it_value set to zero - is it conforming for an implementation of timer_settime() to succeed without an EINVAL error? ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): The intent should be: disarm the timer and ignore the bogus interval value. However, the standard is clear in this respect. Section 2.4, only allows errors to be omitted if they are of the "if detected" variety. The EINVAL return in 14.2.4.4, line 297 SHALL be returned. The description in 14.2.4.2, lines 225-226, states "If the it_value member of value is zero, the timer SHALL be disarmed". A proposed disposition is as follows: The standard states that the function needs to disarm the timer, AND return -1 and set errno to EINVAL, however concerns are being forwarded to the sponsor. Proposed note to project editor (not part of the interpretation): It is recommended that a future revision consider making the the EINVAL return an "if detected" or otherwise reword it so that the function can succeed even with a garbage value of it_interval, so long as it_value is zero. ------------------------------------------------------------------------ Interpretation: --------------- The standard states that the function needs to disarm the timer, AND return -1 and set errno to EINVAL, however concerns are being forwarded to the sponsor. Rationale ------------- None. Note to project editor (not part of the interpretation): -------------------------------------------------------- It is recommended that a future revision consider making the the EINVAL return an "if detected" or otherwise reword it so that the function can succeed even with a garbage value of it_interval, so long as it_value is zero. Forwarded to Interpretations group: 3 May 1998 Proposed interpretation: 17 Jul 1998 Finalised: February 17 1999 _____________________________________________________________________________ PASC Interpretation reference 1003.1-96 #90 _____________________________________________________________________________ Interpretation Number: XXXX Topic: sem_getvalue() Relevant Sections: Page 251 , clause 11.2.8 PASC Interpretation Request: ---------------------------- Date: Sun, 3 May 1998 02:53:28 -0500 ------------------------------------------------------------------------ 7 Defect Report concerning (number and title of International Standard or DIS final text, if applicable): IEEE Std 1003.1-1996 (incorporates 1003.1-1990, 1003.1b-1993, 1003.1c-1995, 1003.1i-1995) (ISO 9945-1:1996) ------------------------------------------------------------------------ 8 Qualifier (e.g. error, omission, clarification required): 3 Error=1 , Omission=2, Clarification=3 ------------------------------------------------------------------------ 9 References in document (e.g. page, clause, figure, and/or table numbers): Page 251 , clause 11.2.8 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): The description for sem_getvalue() states on lines 362-365: "If sem is locked, then the value returned by sem_getvalue() shall be either zero or a negative number whose absolute value represents the number of processes waiting for the semaphore at some unspecified call during the call." Is an implementation that always returns zero when sem is locked conforming? Such an implementation interprets the wording of the specification to be that the return value is EITHER zero OR a negative value .... ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): Yes this is conforming, the intent of the specification is to permit either implementation - either the one that always returns zero or the one that indicates the number of processes waiting on the semaphore. Proposed note to project editor (not part of this interpretation). The rationale should be updated to note that this is the intent. ------------------------------------------------------------------------ Interpretation: --------------- Yes this is conforming. Rationale ------------- As noted in the proposed solution the rationale behind the current specification should allow both behaviours to be conforming. Forwarded to Interpretations group: 3 May 1998 Proposed Interpretation: 17 Jul 1998 Finalised: February 17 1999 _____________________________________________________________________________ PASC Interpretation reference 1003.1-96 #91 _____________________________________________________________________________ Interpretation Number: XXXX Topic: PTHREAD_CANCEL_* symbols required as macros? Relevant Sections: p351, ll 158-159,162-163, 18.2.2.2; plus others PASC Interpretation Request: ---------------------------- Date: Mon, 29 Jun 1998 08:56:59 -0500 From: XXXXXXXXXXXXXXXXXXXXXXXXX ------------------------------------------------------------------------ 7 Defect Report concerning (number and title of International Standard or DIS final text, if applicable): IEEE Std 1003.1-1996 (incorporates 1003.1-1990, 1003.1b-1993, 1003.1c-1995, 1003.1i-1995) (ISO 9945-1:1996) ------------------------------------------------------------------------ 8 Qualifier (e.g. error, omission, clarification required): 3 Error=1 , Omission=2, Clarification=3 ------------------------------------------------------------------------ 9 References in document (e.g. page, clause, figure, and/or table numbers): p351, ll 158-159,162-163, 18.2.2.2; plus others ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): Appendix C describes the following macros for threads support to be present in : PTHREAD_CANCEL_ASYNCHRONOUS PTHREAD_CANCEL_DEFERRED PTHREAD_CANCEL_DISABLE PTHREAD_CANCEL_ENABLE PTHREAD_CREATE_DETACHED PTHREAD_CREATE_JOINABLE PTHREAD_SCOPE_PROCESS PTHREAD_EXPLICIT_SCHED PTHREAD_SCOPE_SYSTEM PTHREAD_INHERIT_SCHED however nowhere in the normative text does it appear to require that these be defined as macros. Is it conforming to define these as enumerated values such as follows? enum { PTHREAD_CREATE_JOINABLE, PTHREAD_CREATE_DETACHED }; enum { PTHREAD_INHERIT_SCHED, PTHREAD_EXPLICIT_SCHED }; enum { PTHREAD_SCOPE_SYSTEM, PTHREAD_SCOPE_PROCESS }; enum { PTHREAD_CANCEL_ENABLE, PTHREAD_CANCEL_DISABLE }; enum { PTHREAD_CANCEL_DEFERRED, PTHREAD_CANCEL_ASYNCHRONOUS }; ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): ------------------------------------------------------------------------ Proposed interpretation: ------------------------- The standard is silent on the issue and either behaviour is conforming. This is being forwarded to the sponsor. Rationale ------------- Annex C is informative and not part of the standard. Note to project editor (not part of the interpretation): -------------------------------------------------------- It is recommended that this issue be clarified in Annex C in a future revision. Forwarded to Interpretations group: 29 June 1998 Proposed Interpretation: 17 Jul 1998 Finalised: February 17 1999 ----- Andrew Josey The Open Group PASC FC Interpretations Apex Plaza,Forbury Road, Email: a.josey@opengroup.org Reading,Berks.RG1 1AX,England Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110 PASC Interpretations Web Site: http://www.pasc.org/interps/