From ajosey@rdg.opengroup.org Tue Aug 29 17:44:50 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 RAA38770 for ; Tue, 29 Aug 2000 17:44:49 +0200 (CEST) (envelope-from ajosey@rdg.opengroup.org) Received: by mailgate.rdg.opengroup.org; id AA05524; Tue, 29 Aug 2000 15:52:46 GMT Received: from skye.rdg.opengroup.org [192.153.166.247] by smtp.opengroup.org via smtpd V1.38 (00/07/25 13:18:13) for ; Tue Aug 29 16:52 BST 2000 Received: (from ajosey@localhost) by skye.rdg.opengroup.org (8.9.3/8.8.7) id QAA03370; Tue, 29 Aug 2000 16:44:30 +0100 Date: Tue, 29 Aug 2000 16:44:30 +0100 From: Andrew Josey Message-Id: <1000829154430.ZM3369@skye.rdg.opengroup.org> Reply-To: ajosey@rdg.opengroup.org (Andrew Josey) X-Mailer: Z-Mail (5.0.0 30July97) To: donnte@microsoft.com Subject: Finalised PASC 1003.1 Interpretations #100,110->116 Cc: stds-pasc-ieee-officers@ieee.org, sc22wg15@dkuug.dk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Mr. Donn Terry From: Andrew Josey, PASC Interpretations Functional Chair Reference: PASC 1003.1-90 #100, 100->106 Dear Mr. Terry, Subject: IEEE Standard 1003.1-1990 Enclosed is the official response for your requests for an 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 _____________________________________________________________________________ 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.1-96 #100 _____________________________________________________________________________ Interpretation Number: XXXX Topic: thread holding a mutex Relevant Sections: P 306, Line 713 PASC Interpretation Request: ---------------------------- From: XXXXXXXXXXXXXXXXXXXX Date: 1999 Sep 9 ------------------------------------------------------------------------ 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 306, Line 713 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): The text in this paragraph is apparently referring to the text at Page 290, line 141. However, the two paragraphs share no common terminology, and thus the meaning is at least partially lost. ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): Minimally, the two should share the same terminology. Better yet is to cross reference the concepts, rather than trying to describe it (in two different ways). Try this instead (change starts at the *): "While a thread is holding...protocol attributes *is not subject to the requirement that it resume execution after all other runnable processes at equal or greater priority have been scheduled to run as required by sched_setparam() and similar calls". (2 places). Also, at line 143, change to read: "except as specified under pthread_mutexattr_getprotocol()". ------------------------------------------------------------------------ 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 ------------- None. Notes to project editor (not part of this interpretation): ----------------------------------------------------------- Suggest change lines 141-143 on page 290 to use "tail" terminology. : The target process, whether it is running or not running, shall be moved to the tail of the thread list for its priority. Forwarded to Interpretations group: 10 Sep 1999 Proposed resolution: 25 July 2000 Finalised interpretation: 29 August 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.1-96 #110 _____________________________________________________________________________ Interpretation Number: XXXX Topic: raise vs asynchronous signal Relevant Sections: 2.2.2.10 , p14 l 120 From: Donn Terry Date: Fri, 16 Jun 2000 17:03:24 -0700 PASC Interpretation Request: ---------------------------- From: Donn Terry Date: 2000 June 16 Ref: XBD 25 Address details: Microsoft Corporation 1 Microsoft Way Redmond, WA 425 705-5091 425 936-7329 Fax (please include email address on cover page) ------------------------------------------------------------------------ 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 14, Line 120 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): Is the result of raise () (or kill() of self) a synchronous or asynchronous signal? ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): This is to bring work in scope for the Austin Group revision. The problem is that synchronous and asynchronous signals are not quite well defined, particularly in the case of raise(). The current wording is "a signal that is not attributable to a specific thread". Since all signals are generated by SOME thread, they are all attributable to a specific thread (just not neccessarily the one handling the signal). I believe the thrust of it is "attributable to the thread handling the signal". Right now, "synchronously generated signal" is being treated as a synonym for "execution fault signal", which it isn't, at least according to the definition of the word "synchronously", because raise() would also be synchronously generated. Suggested alternative wording: Asynchronously generated signal: "A signal that is not attributable to the actions of the thread handling the signal." and Synchronously generated signal: "A signal that is attributable to the thread which is handling it, and which is handled immediately upon its generation; that is, is not blocked or ignored. Note: timer and I/O completion signals are considered attributable to the timer or I/O system." Note... there are two intertwined issues here; please address both of them: 1) "attributable to a process" is trivially true; it's "the same thread" that's critical to fixing this. 2) "handled immediately". This certainly is the intent, but it could be circumvented. Doing a raise() of a signal known to be blocked is not an unreasonable programming technique, but it wouldn't be a synchronous signal. On the other hand, doing a raise() of an unblocked signal is synchronous with the program. (Or... rename the concept to "error signal" or something like that.) ------------------------------------------------------------------------ Interpretation response ------------------------ The answer to the question in the problem statement is "synchronous". The problem raised in the "solution" section is being referred to the sponsor. Rationale ------------- New definitions are required, those proposed will not work, this is referred to the sponsor. Forwarded to Interpretations group: 19 June 2000 Proposed resolution: 25 July 2000 Finalised Interpretation: 29 August 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.1-96 #111 _____________________________________________________________________________ Interpretation Number: XXXX Topic: signal concepts Relevant Sections: p78 line 870, p79 line 883 From: Donn Terry Date: Fri, 16 Jun 2000 17:03:53 -0700 PASC Interpretation Request: ---------------------------- From: Donn Terry Date: 2000 June 16 Ref: XSH 20 Address details: Microsoft Corporation 1 Microsoft Way Redmond, WA 425 705-5091 425 936-7329 Fax (please include email address on cover page) ------------------------------------------------------------------------ 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): P78 L870 P79 L883 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): At 870, there's the "with a single exception clause". At 883 in the sentence beginning with "If" would seem to disallow that exception. (That is, if a return is executed by the handler, all would seem to be required to work right, regardless of what went before.) ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): Replace the sentence with a pointer to the discussion of signal-safe and unsafe functions. ------------------------------------------------------------------------ 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 ------------- None. Notes to project editor (not part of this interpretation): ------------------------------------------------------------ Add "except as ..." on line 870: "...except as noted for unsafe functions". Forwarded to Interpretations group: 19 June 2000 Proposed resolution: 25 July 2000 Finalised interpretation: 29 August 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.1-96 #112 _____________________________________________________________________________ Interpretation Number: XXXX Topic: lseek and the "gap" Relevant Sections: 6.5.3.2 P 162, Line 578 From: Donn Terry Date: Fri, 16 Jun 2000 17:04:00 -0700 PASC Interpretation Request: ---------------------------- From: Donn Terry Date: 2000 June 16 Ref: XSH 393 Address details: Microsoft Corporation 1 Microsoft Way Redmond, WA 425 705-5091 425 936-7329 Fax (please include email address on cover page) ------------------------------------------------------------------------ 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): 1 Error=1 , Omission=2, Clarification=3 ------------------------------------------------------------------------ 9 References in document (e.g. page, clause, figure, and/or table numbers): P 162, Line 578 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): "in the gap" is not well defined; it needs a definition to assure that there is no future disagreement on the meaning. (The problem is that "gap" is the sort of word you'd expect to have a defined meaning, and it doesn't. In the absence of a defined meaning, the reader is left to guess.) ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): "In the region of the file not actually written." seems OK. This appears to be ordinary english. ------------------------------------------------------------------------ Interpretation response ------------------------ The standard is clear, and the term is well understood as part of the English language. No change is required. Rationale ------------- None. Forwarded to Interpretations group: 19 June 2000 Proposed resolution: 25 July 2000 Finalised Interpretation: 29 August 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.1-96 #113 _____________________________________________________________________________ Interpretation Number: XXXX Topic: scheduling Relevant Sections: P 306 L 713, P 290 L 141 From: Donn Terry Date: Fri, 16 Jun 2000 17:04:03 -0700 PASC Interpretation Request: ---------------------------- From: Donn Terry Date: 2000 June 16 Ref: XSH 472 Address details: Microsoft Corporation 1 Microsoft Way Redmond, WA 425 705-5091 425 936-7329 Fax (please include email address on cover page) ------------------------------------------------------------------------ 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 306 L 713 P 290 L 141 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): The phrase "moving to the tail of the scheduling queue" is not defined elsewhere in the document. Although it's intuitively obvious to _authors_ of the document, it is not precise (not legally defendable as meaning the same thing as whatever it DOES mean in a court of law, should it ever come to that). It's apparently referring to the text at P290 L141, but that to some degree is guesswork on my part. The same phrasing is not used. ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): Instead of "moving to the tail of the scheduling queue"... change (starting at the *): "While a thread is holding...protocol attributes *it shall not subject to the requirement that it resume execution after all other runnable processes at equal or greater priority have been scheduled to run as required by sched_setparam() and similar calls". (2 places). Also, add at 34508 (in sched_setparam): "except as specified under pthread_mutexattr_getprotocol()". It would not hurt to collect these requirements together under General Concepts and refer to them from both locations. I'll HELP draft words should that be acceptable, but I'm not expert enough in this area to do it alone. (I believe there's a start to this in the Austin Group draft.) ------------------------------------------------------------------------ Interpretation response ------------------------ The standard is clear, see the definition on page 287, lines 23-27. This is also a duplicate of interpretation #100. No change is required. Rationale ------------- None. Forwarded to Interpretations group: 19 June 2000 Proposed resolution: 25 July 2000 Finalised interpretation: 29 August 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.1-96 #114 _____________________________________________________________________________ Interpretation Number: XXXX Topic: granularity vs resolution Relevant Sections: P310 L63 From: Donn Terry Date: Fri, 16 Jun 2000 17:03:57 -0700 PASC Interpretation Request: ---------------------------- From: Donn Terry Date: 2000 June 16 Ref: XSH 32 Address details: Microsoft Corporation 1 Microsoft Way Redmond, WA 425 705-5091 425 936-7329 Fax (please include email address on cover page) ------------------------------------------------------------------------ 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): P310 L63 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): The pharase "maximum allowable resolution" here is potentially ambiguous. Is it the largest value of _POSIX_CLOCKRES_MIN, or the largest value of 1/_POSIX_CLOCKRES_MIN (which have completely opposite senses) what is intended? "Maximum allowable resolution" can be read as "the maximally finest grained resolution permitted" or "the maximally most granular resolution permitted". Intuitively (which doesn't count) the intent is that the "the worst (most granular) acceptable resolution is...". (If you have trouble seeing the first interpretation of the words, consider a situation where the standard wished to prohibit something from getting too fine grained (say because it would overload the system). "The maximum allowable resolution of the system timer interrupt is 1 microsecond, because any smaller value cannot be serviced before the next timer interrupt occurs.") ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): Change "maximum" to either "poorest" or "largest allowable granularity". ------------------------------------------------------------------------ Interpretation response ------------------------ (note this is a dup of #99 which is also open) The standard is clear, there is a good definition already. No change is required. Rationale ------------- None. Forwarded to Interpretations group: 19 June 2000 Proposed resolution: 25 July 2000 Finalised interpretation: 29 August 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.1-96 #115 _____________________________________________________________________________ Interpretation Number: XXXX Topic: mprotect v mmap Relevant Sections: 12.2.3.2 , 12.2.1.2, p272 l220, p278 l416 From: Donn Terry Date: Fri, 16 Jun 2000 17:04:01 -0700 PASC Interpretation Request: ---------------------------- From: Donn Terry Date: 2000 June 16 Ref: XSH 408 Address details: Microsoft Corporation 1 Microsoft Way Redmond, WA 425 705-5091 425 936-7329 Fax (please include email address on cover page) ------------------------------------------------------------------------ 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) --- and as amended by .1a, .1d and .1j. ------------------------------------------------------------------------ 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): I don't have the various as-amended copies available, but in the Austin Group draft, where they all appear together: P746 Line 23499 and P737 L 23168 (2d sentence of paragraph on) ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): It would appear that the two paragraphs should be saying the same thing (identically) and they do not, particularly the bit about the _POSIX_MEMORY_PROTECTION option. ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): At least reconcile the two paragraphs. However, it would be better to remove the duplication (by moving it to a section of general concepts) and refer to the resultant text there. (I suspect that one or the other paragraphs (probably the one at 23167) is correct as it stands.) ------------------------------------------------------------------------ Interpretation response ------------------------ The standard is clear; _POSIX_MEMORY_PROTECTION covers all of mprotect but only part of mmap. No change is required. Rationale ------------- None. Forwarded to Interpretations group: 19 June 2000 Proposed resolution: 25 July 2000 Finalised interpretation: 29 August 2000 [note, not part of this interpretation: an observation on 10 above, one reason they do not have a statement about the Memory Protection option in mprotect() is that the whole function is only supported in .1-1996 when the option is supported, hence specifying semantics in that case makes no sense] _____________________________________________________________________________ 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.1-96 #116 _____________________________________________________________________________ Interpretation Number: XXXX Topic: buffer sizes in characters or bytes Relevant Sections: P 226, Line 49, P 228, Line 105 From: Donn Terry Date: Fri, 16 Jun 2000 17:03:55 -0700 PASC Interpretation Request: ---------------------------- From: Donn Terry Date: 2000 June 16 Ref: XSH 301 Address details: Microsoft Corporation 1 Microsoft Way Redmond, WA 425 705-5091 425 936-7329 Fax (please include email address on cover page) ------------------------------------------------------------------------ 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): 1 Error=1 , Omission=2, Clarification=3 ------------------------------------------------------------------------ 9 References in document (e.g. page, clause, figure, and/or table numbers): P 226, Line 49 P 228, Line 105 ------------------------------------------------------------------------ 10 Nature of defect (complete, concise explanation of the perceived problem): "Characters" is not a measure of storage. "Bytes" is. Here storage, not (potentially multi-byte) characters, is intended. ------------------------------------------------------------------------ 11 Solution proposed by the submitter (optional): "characters" -> "bytes" ------------------------------------------------------------------------ Interpretation response ------------------------ The standards states characters, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale ------------- None. Notes to project editor (not part of the interpretation): -------------------------------------------------------- Action the solution in section 11. Forwarded to Interpretations group: 19 June 2000 Proposed resolution: 25 July 2000 Finalised Interpretation: 29 August 2000 ----- 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/