From rinehuls@access.digex.net Wed Oct 8 22:40:09 1997 Received: from access1.digex.net (qlrhmEbBUV1EY@access1.digex.net [205.197.245.192]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id WAA10664 for ; Wed, 8 Oct 1997 22:39:19 +0100 Received: from localhost (rinehuls@localhost) by access1.digex.net (8.8.4/8.8.4) with SMTP id RAA22202 for ; Wed, 8 Oct 1997 17:38:59 -0400 (EDT) Date: Wed, 8 Oct 1997 17:38:59 -0400 (EDT) From: "william c. rinehuls" X-Sender: rinehuls@access1.digex.net Reply-To: "william c. rinehuls" To: sc22docs@dkuug.dk Subject: SC22 N2593 - Record of Responses for Defect Reports 1 - 11 to Amendment 1 of 9945-1 - POSIX C Binding Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ____________________ beginning of title page _____________________ ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N2593 TITLE: WG15 Record of Responses for Defect Reports 1 through 11 for Amendment 1 to ISO/IEC 9945-1:1990 - Information technology - Portable Operating System Interface (POSIX) - POSIX C Binding And Letter Ballot DATE ASSIGNED: 1997-10-07 SOURCE Secretariat, ISO/IEC JTC 1/SC22 BACKWARD POINTER: N/A DOCUMENT TYPE: Record of Responses for Defect Reports PROJECT NUMBER: JTC 1.22.21.04.01 STATUS: In accordance with SC22 N1236, non-responses to the letter ballot will be considered as agreement with the proposed record of responses. Note that Amendment 1 was incorporated into ISO/IEC 9945-1 when it was revised in 1996. ACTION IDENTIFIER: ACT DUE DATE: 1998-02-09 DISTRIBUTION: Text CROSS REFERENCE: N/A DISTRIBUTION FORM: Open Address reply to: ISO/IEC JTC 1/SC22 Secretariat William C. Rinehuls 8457 Rushing Creek Court Springfield, VA 22153 USA Telephone: +1 (703) 912-9680 Fax: +1 (703) 912-2973 email: rinehuls@access.digex.net __________________end of title page; beginning of letter ballot _______ ----------------------------------------------------------------------- Attachment to JTC 1/SC22 N2593 Circulation Date: 10-24-97 LETTER BALLOT FROM THE MEMBER BODY OF __________________________________ On WG15 Proposed Record of Responses for Defect Reports 01 through 11 for Amendment 1 to ISO/IEC 9945-1:1990 - Information technology - Portable Operating System Interface (POSIX) - POSIX C Binding This letter ballot is to be returned by each "P" Member Body to the Secretariat of JTC 1/SC22 by FEBRUARY 9, 1998 ------------------------------------------------------------------------ _____ We agree with the Record of Responses or _____ We agree with the Record of Responses with the attached comments or _____ We do not agree with the Record of Responses for the technical reasons attached to this ballot. or _____ We abstain from voting ("P" MEMBERS HAVE AN OBLIGATION TO VOTE) * CHECK WHICHEVER APPLIES. Name (please print) ______________________ Signature (if mailed) ___________________ Date: _______________ ------------------------------------------------------------------------ ____________end of letter ballot; beginning of document ____________ WG15 Record of Responses for Defect Reports 01 through 11 for Amendment 1 to ISO/IEC 9945-1:1990 - Information technology - Portable Operating System Interface (POSIX) - POSIX C Binding Below find 10 Record of Responses for interpretations/defects as reported by the U.S. to WG15. These are numbered with the Standard (IS 9945-1Amd1), followed by a tracking number used in the U.S. This is proposed to SC22 as a Record of Responses for approval by SC22 for the defects/interpretations indicated in the text. The specific Defect Reports included are Defect Reports 1, 2, 3, 4 and 6 through 11. Defect Report 5 either did not require a record of response (withdrawn, Technical Corrigenda) or it has not yet resulted in an accepted response. ISO/IEC 9945-1-amd1 Interpretations Log ------------------------------------------------------------------------ 9945-1-amd1-01 Topic: async IO Relevant Sections: 6.7.4.2 9945-1-amd1-02 Topic: action on synchronous signal acceptance Relevant Sections: 3.3.1.3 9945-1-amd1-03 Topic: mmap Relevant Sections: 12.2.1.2 9945-1-amd1-04 Topic: mmap Relevant Sections: 12.2.1 9945-1-amd1-06 Topic: semaphores Relevant Sections: 11.2.3.2, page 222, lines 110-118 9945-1-amd1-07 Topic: sigaction Relevant Sections: 3.3.4.2. Page 72 lines 915-923 9945-1-amd1-08 Topic: ftruncate Relevant Sections: 5.6.7.2 lines 1017-1018 9945-1-amd1-09 Topic: _POSIX_PRIORITIZED_IO part 1 Relevant Sections: 6.7.1.1 9945-1-amd1-10 Topic: _POSIX_PRIORITIZED_IO part 2 Relevant Sections: 6.7.1.1 9945-1-amd1-11 Topic: _POSIX_PRIORITIZED_IO part 3 Relevant Sections: 6.7.1.1 ---------------------------------------------------------------------- WG15 Defect Report Ref: 9945-1-amd1-01 Topic: async IO 9945-1-amd1-93 #01 Defect Report Number: (to be assigned by WG15) Topic: async IO Relevant Sections: 6.7.4.2 Classification: See responses below. Defect Report: ----------------------- I have a couple of question on the async IO section of POSIX 1003.b1-1993. Reading section 6.7.4.2 (the description of the lio_listio call) I am not clear on: 1) does the sigev_notify field need to be filled in the sig argument to lio_listio. The generic section on the aiocb (6.7.1.1) talks about the use of the sigev_notify field, however the section on lio_listio described different requirements using the same structure. 1b) If not can it be filled in, and what is the behavior if for example the sigev_filed was set to SIGEV_NONE and the sigev_signo is non zero. 2) If a user puts valid values in the sigev_notify and sigev_signo fields in members of the aiocb list in a call to lio_listio() what happens? Are they ignored, do that happen as well as/instead of the event that is described by *sig argument. WG15 response for 9945-1-amd1-1993 ------------------------------------ 1. The standard is clear that SIGEV_NOTIFY is ignored and a signal shall be sent. Conforming implementations must conform to this. This is different from the definition in section 3.3.1.2 and which the interpretation committee views as a defect in the standard. This fact is being refered to the sponsor for consideration. The interpretation committee suggests that applications might wish to consistently set SIGEV_NOFTIFY and SIGEV_SIGNO so that the application would continue to work correctly if the standard is changed. 2. The standard is clear that in the case raised, that a signal is generated at the completion of each i/o operation where sigev_signo is non-zero and one is also generated when the entire set of operations is completed. Conforming implementations must conform to this. Rationale ---------- None. ________________________________________________________________________ WG15 Defect Report Ref: 9945-1-amd1-02 Topic: action on synchronous signal acceptance 9945-1-amd1-93 #2 Defect Report Number: (to be assigned by WG15) Topic: action on synchronous signal acceptance Relevant Sections: 3.3.1.3 Classification: Ambiguous Defect Report: ----------------------- Section 3.3.1.3 defines actions for signals. The circumstance under which these actions are to be taken is termed delivery in 3.3.1.2. Also, in 3.3.1.2, the statement is made that signals can be blocked from delivery, and remain pending until either unblocked or the action is set to ignore. No mention is made of synchronous acceptance, as specified by sigwaitinfo() and sigtimedwait() (3.3.8). My questions apply when a signal is synchronously accepted. 1) Is an implementation required to take the associated action when a signal is accepted synchronously? 2) Is an implementation permitted to take the associated action when a signal is accepted synchronously? 3) Is an implementation forbidden to take the associated action when a signal is accepted synchronously? WG15 response for 9945-1-amd1-1993 ------------------------------------ The standard is not clear in this area. It is ambiguous as to whether the synchronous selection of a signal by sigwaitinfo constitutes delivery or not. The interpretation is that an implementation is permitted to take the associated action when a signal is accepted synchronously: neither required nor forbidden. The lack of clarity is being refered to the sponsor for consideration. The interpretations committee suggests that an application would prefer to only receive each signal once and that implementations might wish to implement the factility in this manner (which is allowed but not required). The answers to the requestor's 3 questions are thus: no, yes, no. Rationale ---------- None. ________________________________________________________________________ WG15 Defect Report Ref: 9945-1-amd1-03 Topic: mmap 9945-1-amd1-93 #3 Defect Report Number: (to be assigned by WG15) Topic: mmap Relevant Sections: 12.2.1.2 Classification: (to be assigned) Defect Report: ------------------- I'd like to receive clarification on text I read in 9945-1-amd1-1993. Specifically the question has to do with mmap() and what is meant by the following(removed word for word from page 236, lines 213-215): "The mapping established by mmap() replaces any previous mappings for those whole pages containing any part of the process's address space starting at "pa" and continuing for "len" bytes." There are a couple of ways this can be interpreted and I'd like to find out which is the intended one. a) Does this mean if I map page 3 of a file in one call and page 5 in another call and then map pages 3-5 in a separate call, the call succeeds and the previous mappings of page 3 and page 5 are no longer valid? If so, does that apply to both MAP_PRIVATE and MAP_SHARED? b) Does this apply to MAP_FIXED where lets say the user has page 1 of file A mapped at address 0x40005000 and then a mmap(MAP_FIXED) at address 0x40004000 for three pages(range 0x40004000-0x40006fff) on file B overwrites the other mmap? In other words am I allowed overlay mappings with different files? If so, both MAP_SHARED and MAP_FIXED? c) Does the overwrite only apply to mmap() collisions or any address collision. For instance, can a process mmap() over its data object or other non mmap objects? WG15 response for 9945-1-amd1-1993 ------------------------------------ For question a), the standard is clear that the mapping is replaced the addresses overlap but not replaced where they don't. Page 238 line 274: "...nor shall it replace an extant mapping." Part one of the question: ... the other mappings are no longer valid? -> this is incorrect, unless the addresses are specified in MAP_FIXED and overlap. The standard is clear that this applies to both MAP_PRIVATE and MAP_SHARED. Question b, the standard is clear that you can replace the existing mappings using MAP_FIXED independent of MAP_SHARED and MAP_PRIVATE. Question c, the standard is silent on whether you can map over objects other than ones mapped by MMAP. Implementations can allow MAP_FIXED mapping over other kinds of memory or not allow it. Rationale ---------- None. WG15 Defect Report Ref: 9945-1-amd1-04 Topic: mmap 9945-1-amd1-4 Defect Report Number: 9945-1-amd1-4 Topic: mmap Relevant Sections: 12.2.1 Classification: (to be assigned) Defect Report: ----------------------- ISO/IEC 9945-1:1990 defines file times (access time and modification time), and specifies in detail how functions in that standard effect the file times. ISO/IEC 9945-1-amd1-1993 adds the mmap() function (12.2.1) as a completely new way to access a regular file. However, It does not seem to specify how accesses to a file via mmap() affect the file times. To be specific, when shall, and when may, the implementation mark st_atime and st_mtime for update in each of the following cases: (1) mmap() is called with PROT_READ. (2) mmap() is called with MAP_SHARED and PROT_WRITE. (3) Application modifies a page previous mapped with MAP_SHARED, PROT_WRITE. (4) Application references a page mapped MAP_PRIVATE that has not been modified by the process. (Keep in mind that the process might be seeing data that has changed since the mmap().) (5) Application modifies a page mapped MAP_PRIVATE, PROT_WRITE. (6) Application references a page mapped MAP_PRIVATE that was previously modified by the process. (7) msync() (12.2.4) is called on pages mapped with mmap(). WG15 response for 9945-1-amd1-1993 ------------------------------------ The standard is silent on this matter. The committee notes that this is inconsistent with page 27 line 626 which states generally that it should specified and this matter is being referred to the sponsor for consideration. Rationale ---------- None. WG15 Defect Report Ref: 9945-1-amd1-06 Topic: semaphores 9945-1-amd1-93 #6 Topic: semaphores Relevant Sections: 11.2.3.2, page 222, lines 110-118 Defect Report: ----------------------- Section 11.2.3.2, page 222, lines 110-118 What are the meanings of read and write permissions with respect to semaphores? Is there a method of opening an existing semaphore for O_RDONLY or O_RDWR or O_WRONLY? What is the effect of calling sem_wait, sem_trywait or sem_post on a semaphore which was created with read-only permission? Write-only permission? The standard does not specify a behavior if the semaphore was not created with both read and write permissions. Should the post and wait operations require both read/write access since this is both a read and write operation? There is no error return for this situation. Interpretation response ------------------------ The standard is clear: only the the O_CREAT and O_EXCL flags have a defined interpretation. The other flags are unspecified and a strictly conforming application will not use them. Any usage or interpretations of the flags by an implementation would be an extension. Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd1-07 Topic: sigaction 9945-1-amd1-93 #7 Topic: sigaction Relevant Sections: 3.3.4.2. Page 72 lines 915-923 Defect Report: ----------------------- ISO/IEC 9945-1-amd1-1993 Section 3.3.4.2. Page 72 lines 915-923 describes what happens if a signal is pending that is dispatched at a time when a signal handler was in place expecting three arguments. This section does not describe what happens to the second and third arguments of a signal handler that catches a signal that was dispatched when a signal handler expecting one argument was installed. What is the conformant behaviour in this case? Interpretation response ------------------------ The question as asked has some ambiguity and would have different answers based up which question is meant If a signal is generated during a time that SA_SIGINFO is set in sa_flags, sigqueue can pass a si_value and the signal has an associated si_code. If sigaction is called with sa_flags clear, then the standard is clear that 'the signal-catching function shall be invoked with only a single argument' (pg 72 line 917): the signo is delivered. If a signal is generated during a time that SA_SIGINFO is cleared in sa_flags, sigqueue still has a si_value and the associated si_code. If sigaction is then called before delivery with sa_flags set, then the standard is clear that 'The application specified value shall be passed to the signal-catching function...' (pg 72 line 922-923). Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd1-08 Topic: ftruncate 9945-1-amd1-93 #8 Topic: ftruncate Relevant Sections: 5.6.7.2 lines 1017-1018 Defect Report: This section states "The ftruncate() function marks the st_ctime and st_mtime fields of the file." Other interfaces such as write() have similar but different wording: ".. shall mark for update the st_ctime ... fields of the file." Are these phrases "marks the ... fields of the file" and "shall mark for update.." equivalent? Interpretation response ------------------------ The meaning of the phases is the same. This is an editorial oversight and the committee has requested that the project editor change the first occurance to "...shall mark for update.." in section 5.6.7.2 line 1017. Rationale ------------- None. WG15 Defect Report Ref: 9945-1-amd1-09 Topic: _POSIX_PRIORITIZED_IO part 1 9945-1-amd1-93 #9 Defect Report Number: (to be assigned by WG15) Topic: _POSIX_PRIORITIZED_IO part 1 Relevant Sections: 6.7.1.1 Classification: (to be assigned) Defect Report: FOR ISO/IEC 9945-1-amd1-1993: 1b. Subsection 6.7.1.1, Page 152-153, Lines 729-732: Regarding the option identified by {_POSIX_PRIORITIZED_IO}, the statement says "When prioritized asynchronous I/O requests to the same file are blocked waiting for a resource required for that I/O operation, the higher-priority I/O requests shall be granted the resource before lower-priority I/O requests are granted the resource." The statement is ambiguous with regard to the word "resource". Are the resources (to be considered) ONLY the resources managed by the OS implementation? Once an output request, for example, has been passed from the OS to a smart controller or device, is that output considered completed as far as async I/O concerned? Is the smart controller then permitted to re-order actual writes to a physical device without the knowledge of the OS (which claims to support the Prioritized I/O option)? Assuming that the interpretation answers "yes" to the above questions (which are all logically equivalent questions), I suggest that the semantics of the Prioritized I/O option be clarified to indicate that the "resource" referenced by this sentence is a resource for which contention is managed by the OS implementation, and not resources invisible to the OS implementation. WG15 response for 9945-1-amd1-1993 ------------------------------------ The standard is clear. On page 152 lines 723-727 it states that for character special files the requests are processd in FIFO order by the underlying device and for any other type, the order of processing is unspecified. Rationale ---------- None. WG15 Defect Report Ref: 9945-1-amd1-10 Topic: _POSIX_PRIORITIZED_IO part 2 9945-1-amd1-93 #10 Defect Report Number: (to be assigned by WG15) Topic: _POSIX_PRIORITIZED_IO part 2 Relevant Sections: 6.7.1.1 Classification: (to be assigned) Defect Report: FOR ISO/IEC 9945-1-amd1-1993: 1b2. Subsection 6.7.1.1, Page 152-153, Lines 729-732: Regarding the option identified by {_POSIX_PRIORITIZED_IO}, the statement says "When prioritized asynchronous I/O requests to the same file are blocked waiting for a resource required for that I/O operation, the higher-priority I/O requests shall be granted the resource before lower-priority I/O requests are granted the resource." The statement does not address a common situation involving multiple files and a single resource. If prioritized asynchronous I/O requests to DIFFERENT files are blocked waiting for the SAME resource, shall higher-priority I/O requests be granted that resource before lower-priority I/O requests, regardless of which file? It only seems logical, given the effect which this option is intended to achieve - scheduling async I/O based on priority; it seems that the writers didn't consider the very obvious situation of a physical disk (resource) which implements several files. Assuming that the interpretation answers "yes" to the above question, I suggest that the semantics of the Prioritized I/O option be clarified to explicitly address the case of multiple files per device, indicating that the prioritization of granting the resource (device) is still priority based, and not undefined as it is now. WG15 response for 9945-1-amd1-1993 ------------------------------------ The standard is silent on the question of the relative ordering of requests to different devices. A conforming system is not constrained by the standard as to which order to handle the requests and a conforming applications must be able to handle any ordering. Rationale ---------- The interpretations committee believes that this was the intent of the working and balloting group in this area in order to avoid additional complexity and problems with devices that the groups were not familar. WG15 Defect Report Ref: 9945-1-amd1-11 Topic: _POSIX_PRIORITIZED_IO part 3 9945-1-amd1-93 #11 Defect Report Number: (to be assigned by WG15) Topic: _POSIX_PRIORITIZED_IO part 3 Relevant Sections: 6.7.1.1 Classification: (to be assigned) Defect Report: FOR ISO/IEC 9945-1-amd1-1993: 1b3. Subsection 6.7.1.1, Page 153, Lines 733-734: The statement says "If {_POSIX_PRIORITIZED_IO} is defined, the implementation shall define for which files I/O prioritization is supported". The statement, as written, creates an untestable situation. Is an implementation which defines _POSIX_PRIORITIZED_IO, but defines no files for which I/O prioritization is supported (i.e. says it is supported for no files), a conforming implementation? It appears that if this were allowed, there would be no way to test conformance to the optional capabilities. Assuming that the interpretation answers "no" to the above question, I suggest that the sentence be clarified by also stating that "at least one implementation-defined file shall support I/O prioritization if this option is defined". WG15 response for 9945-1-amd1-1993 ------------------------------------ The standard is clear that it is implementation defined as to which, if any, files support the prioritized I/O option. This is testable by reading the conformance documentation which shall be provided by a conforming implementation. It is expected that any strictly conforming application will be cognizant of the implementation limitations and use that knowledge in the selection of systems to use. Rationale ---------- ________________ end of SC22 N2593 _______________________________