From rinehuls@access.digex.net Mon Sep 15 19:21:33 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 TAA11859 for ; Mon, 15 Sep 1997 19:21:19 +0200 Received: from localhost (rinehuls@localhost) by access1.digex.net (8.8.4/8.8.4) with SMTP id NAA26187 for ; Mon, 15 Sep 1997 13:21:10 -0400 (EDT) Date: Mon, 15 Sep 1997 13:21:10 -0400 (EDT) From: "william c. rinehuls" To: sc22docs@dkuug.dk Subject: SC22 N2583 - WG15 Record of Responses for ISO/IEC 13210 WITH LETTER BALLOT 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 N2583 TITLE: WG15 Record of Responses for Defect Reports 1 through 17 for: ISO/IEC 13210:1994 - Information technology - Portable Operating System Environment (POSIX) - Test Methods for Measuring Conformance to POSIX, AND LETTER BALLOT DATE ASSIGNED: 1997-09-12 SOURCE: Secretariat, ISO/IEC JTC 1/SC22 BACKWARD POINTER: N/A DOCUMENT TYPE: Record of Responses for Defect Reports PROJECT NUMBER: JTC 1.22.37 STATUS: In accordance with SC22 N1236, non-responses to the letter ballot will be considered as agreement with the proposed record of responses. ACTION IDENTIFIER: ACT DUE DATE: 1998-01-29 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 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 N2583 Circulation Date: 10-13-97 LETTER BALLOT FROM THE MEMBER BODY OF: ________________________________ On WG15 Proposed Record of Responses for Defect Reports 01 through 17 to: ISO/IEC 13210:1994 - Information technology - Portable Operating System Environment (POSIX) - Test Methods for Measuring Conformance to POSIX This letter ballot is to be returned by each "P" Member Body to the Secretariat of JTC 1/SC22 by JANUARY 29, 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" MEMBER BODIES HAVE AN OBLIGATION TO VOTE.) * CHECK WHICHEVER APPLIES. Name (please print) _________________________ Signature: _________________________________ Date: _____________ _____________ end of letter ballot; beginning of text _________________ WG15 Record of Responses for Defect Reports 1 through 17 for ISO/IEC 13210:1994 - Information technology - Portable Operating System Environment (POSIX) - Test Methods for Measuring Conformance to POSIX Below find 8 Records of Response for interpretations/defects as reported by the U.S. to WG15. These are numbered with the Standard (13210:1994), 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. As the result of dialog with the initiator of Defect Reports 2, 3, 6, 8, 9, 10, 11, 12 and 16, these Reports were withdrawn by the initiator. The specific Defect Reports included are Defect Reports 1, 4, 5, 7, 13, 14, 15 and 17. ==================================================================== 13210-01 Topic: fflush & EBADF Relevant Sections: 8.1.11.1 13210-04 Topic: link() and PCD_LINK_FILE_SYSTEM Relevant Sections: p117n65/6 13210-05 Topic: rename() and PCD_LINK_FILE_SYSTEM 13210-07 Topic: fgetc(), _POSIX_JOB_CONTROL & SIGTTIN 13210-13 Topic: Appropriate privileges and portable assertions Relevant Sections: p462n24 13210-14 Topic: fflush & EBADF Relevant Sections: 8.1.11.1 13210-15 Topic: abort() and SIGABRT ignore/block/caught Relevant Sections: 8.2.3 13210-17 Topic: tcflow Relevant Sections: 7.2.2.3.2 ======================================================================= WG15 Defect Report Ref: 13210-01 Topic: fflush & EBADF ----------------------------------------------------------------------- 13210-9 2 #1,#14 Classification: duplicate request These are duplicates of WG15 interpretation 9945-1-90 #23. Refer to 9945-1-90 #23 for the response, published in 1Q94. ______________________________________________________________________ Topic: fflush & EBADF Relevant Sections: 8.1.11.1 Defect Report: ----------------------- 13210-92 #1 Assertion 6 of subclause 8.1.11.1 of ISO/IEC 13210:1994 states: 06(A) When the stream pointer argument addresses a file descriptor that is closed, then a call to fflush() returns a value of EOF and sets errno to [EBADF]. Is this correct? The requirements for error reporting for fflush() are in 8.2.3.11 of 9945-1- 1990: If any of the functions above return an error indication, the value of errno shall be set to indicate the error condition. If that error condition is one that this part of ISO/IEC 9945 specifies to be detected by one of the corresponding underlying functions, the value of errno shall be the same as the value specified for the underlying function. The C Standard says only this about error returns from fflush(): The fflush function returns EOF if a write error occurs, otherwise zero. The C Standard does not specify when a write error occurs. The unconditional requirement that fflush() detect a bad file descriptor would seem to go beyond the requirements of POSIX.1. For example, if no data is present in the buffer for the stream on which fflush() is called, it is conforming for fflush() to return success without making any attempt to access the file descriptor associated with the stream. Since there is no need to call write() (the underlying function for fflush()) there is no guarantee that there will be a write error. My feeling is that an assertion that referred to data in the buffer would be conforming: 06(C) If the implementation supports buffered streams: When the stream pointer argument addresses a file descriptor that is closed and there is data in the buffer for the stream pointed to, then a call to fflush() returns a value of EOF and sets errno to [EBADF]. 13210-92 #14: The ISO/IEC 13210:1994 has the following assertion for fflush(): 06(A) When a stream pointer argument addresses a file descriptor that is closed, then a call to fflush() returns a value of EOF and sets errno to [EBADF]. The corresponding test in the NIST PCTS 151-2 beta test suite has a test strategy as follows: fd = Zopen(path, O_RDONLY | O_CREAT, PROT_ALL); sfd = Zfdopen(fd, "r"); Zclose(fd); expecting(EOF); expecting(EBADF); Zfflush(sfd); The problem is the requirement that this strategy places that fflush() return -1 in this case when we have a read stream. Rationale: For write streams, fflush() has to be sure that any buffered data is written. For read streams, fflush() has to discard any buffer contents and adjust the current seek address. For read/write streams, fflush() has to enable a change in I/O direction. Given that in the above code fragment there is no underlying operation to perform (there isn't even a buffer, let alone any contents to ignore), there should not be a requirement to return an EBADF error. Only the C standard and 9945-1 own the rules for fflush(). There is no requirement that we can find in either that corresponds to the above. Moreover, the above would require adding an otherwise useless system call to fflush(). Think about the precedent that this would set: Theoretically, this would imply that, unless granted immunity, each stdio function would have to do test-the-file- descriptor code whenever it didn't happen to get to an underlying operation that would do the verification already. All the test assertions in 13210 are supposed to follow directly from 9945-1 statements. The assertion quoted above has no basis in POSIX.1. We recommend that this assertion not apply to read streams. WG15 response for 13210:1994 -------------------------------------------------- The interpretation for 9945-1-90 #23 applies to these requests : 13210-92 #1, and 13210-92 #14. Rationale for Interpretation: ----------------------------- See 9945-1-90 #23. ______________________________________________________________________ WG15 Defect Report Ref: 13210-04 Topic: link() and PCD_LINK_FILE_SYSTEM ----------------------------------------------------------------------- 13210-9 2 #4 Classification: Editorial defect ______________________________________________________________________ Topic: link() and PCD_LINK_FILE_SYSTEM Relevant Sections: p117n65/6 Defect Report: ----------------------- POSIX 13210 states: Page 177, lines 1393-1403. 65(C) If {PCD_LINK_FILE_SYSTEM} is FALSE: When the link named by new and the file named by existing are on different file systems, then a call to link(existing, new) returns a value of (int)-1, sets errno to [EXDEV], creates no link, and the link count of the file referenced by existing remains unchanged. 66(C) If {PCD_LINK_FILE_SYSTEM} is not documented: When the link named by new and the file named by existing are on different file systems, then a call to link(existing, new) is either successful or returns a value of [(int)-1], sets errno to [EXDEV], creates no link, and the link count of the file referenced by existing remains unchanged. Problem: These assertions require a second file system to test the assertion. The availability of a second file system is a "testing constraint". Action: Replace in each assertion above "(C)" with "(PCTS_FS?C:UNTESTED)". Also, add to the "Testing Constraints", Table 1.1, page 9, line 292 the entry: "PCTS_FS Implementation provides another file system." WG15 response for 13210:1994 ----------------------------------- The problem and actions statements are accepted as written. The standard does not completely specify the testing constraints for these assertions. This is an editorial omission. This will be documented in an errata for the document and also referred to the sponsor for clarifying wording in the next amendment, with the suggested action being the action stated in the original text above. Rationale for Interpretation: ----------------------------- None. ______________________________________________________________________ WG15 Defect Report Ref: 13210-05 Topic: rename() and PCD_LINK_FILE_SYSTEM ----------------------------------------------------------------------- 13210-9 2 #5 Classification: Editorial defect ______________________________________________________________________ Topic: rename() and PCD_LINK_FILE_SYSTEM Relevant sections: p202n68/9 Interpretation request ----------------------- Page 202, lines 2378-2386: (WG15 ref: 13210-93 #5) 68(C) If {PCD_LINK_FILE_SYSTEM} is FALSE:" When the links named by old and new are on different file systems, then a call to rename(old, new) returns a value of (int)-1, sets errno to [EXDEV], and the named files are not changed. 69(C) If {PCD_LINK_FILE_SYSTEM} is not documented: When the links named by old and new are on different file systems, then a call to rename(old, new) is either successful or returns a value of (int)-1, sets errno to [EXDEV], and the named files are not changed. Problem: These assertions require a second file system to test the assertion. The availability of a second file system is a "testing constraint". Action: Replace in each assertion above "(C)" with "(PCTS_FS?C:UNTESTED)". Also, add to the "Testing Constraints", Table 1.1, page 9, line 292 the entry: "PCTS_FS Implementation provides another file system." WG15 response for 13210:1994 ----------------------------------- The problem and actions statements are accepted as written. The standard does not completely specify the testing constraints for these assertions. This is an editorial omission. This will be documented in an errata for the document and also referred to the sponsor for clarifying wording in the next amendment, with the suggested action being the action stated in the original text above. Rationale for Interpretation: ----------------------------- None. ______________________________________________________________________ WG15 Defect Report Ref: 13210-07 Topic: fgetc(), _POSIX_JOB_CONTROL & SIGTTIN --------------------------------------------------------------------- 13210-9 2 #7 Classification: Editorial defect ______________________________________________________________________ _______ Topic: fgetc(), _POSIX_JOB_CONTROL & SIGTTIN Relevant sections: p336n8 Interpretation request ---------------------- Page 336, lines 592-596: (WG15 ref: 13210-93 # 7) 08(C) If the behavior associated with {_POSIX_JOB_CONTROL} is supported: When the process is ignoring or blocking the SIGTTIN signal and is a member of a background process group, and the stream argument references the controlling terminal, then a call to fgetc(stream) returns a value of EOF and sets errno to [EIO]. Also: fgets[8], fread[8], getc[8], getchar[8], gets[8], scanf[8-9], fscanf[8-9]. Problem: A GTI device is required to test these assertions. See the classification of fgetc[9] which should have the same classification as fgetc[8]. Action: Replace in each assertion above "(C)" with "(PCTS_GTI_DEVICE?C:UNTESTED)". WG15 response for 13210:1994 ----------------------------------- The problem and actions statements are accepted as written. The standard does not completely specify the testing constraints for these assertions. This is an editorial omission. This will be documented in an errata for the document and also referred to the sponsor for clarifying wording in the next amendment, with the suggested action being the action stated in the original text above. Rationale for Interpretation: ----------------------------- None. ______________________________________________________________________ WG15 Defect Report Ref: 13210-13 Topic: Appropriate privileges and portable assertions ---------------------------------------------------------------------- 13210-9 2 #13 Classification: Editorial defect ______________________________________________________________________ _______ Topic: Appropriate privileges and portable assertions Relevant Sections: p462n24 Defect Report: ----------------------- Page 462, lines 420-425: (WG15 ref: 13210-93 #13) 24(C) If the implementation requires appropriate privileges to set specific mode bits: When the utility restoring the files from the archive does not have the required appropriate privileges to set a given mode bit and this privilege is required, then the mode bits for which the process does not have these privileges are ignored. Problem: The conditionals for Assertion #24 require one or documentation assertions to specify how the test is to be performed and what is the expected outcome. Since these documentation assertions would be conditional on "documentation being provided", this assertion cannot be portably tested. Action: Replace "24(C)" with "24(D)". Also add after line 425: Section 5 of POSIX.3." WG15 response for 13210:1994 ----------------------------------- The problem and actions statements are accepted as written. The standard does not completely specify the testing constraints for these assertions. This is an editorial omission. This will be documented in an errata for the document and also referred to the sponsor for clarifying wording in the next amendment, with the suggested action being the action stated in the original text above. Rationale for Interpretation: ----------------------------- None. ______________________________________________________________________ WG15 Defect Report Ref: 13210-14 Topic: fflush & EBADF ----------------------------------------------------------------------- 13210-9 2 #1,#14 Classification: duplicate request These are duplicates of WG15 interpretation 9945-1-90 #23. Refer to 9945-1-90 #23 for the response, published in 1Q94. ______________________________________________________________________ Topic: fflush & EBADF Relevant Sections: 8.1.11.1 Defect Report: ----------------------- ISO/IEC 13210-92 #1 Assertion 6 of subclause 8.1.11.1 of ISO/IEC 13210:1994 states: 06(A) When the stream pointer argument addresses a file descriptor that is closed, then a call to fflush() returns a value of EOF and sets errno to [EBADF]. Is this correct? The requirements for error reporting for fflush() are in 8.2.3.11 of 9945-1- 1990: If any of the functions above return an error indication, the value of errno shall be set to indicate the error condition. If that error condition is one that this part of ISO/IEC 9945 specifies to be detected by one of the corresponding underlying functions, the value of errno shall be the same as the value specified for the underlying function. The C Standard says only this about error returns from fflush(): The fflush function returns EOF if a write error occurs, otherwise zero. The C Standard does not specify when a write error occurs. The unconditional requirement that fflush() detect a bad file descriptor would seem to go beyond the requirements of POSIX.1. For example, if no data is present in the buffer for the stream on which fflush() is called, it is conforming for fflush() to return success without making any attempt to access the file descriptor associated with the stream. Since there is no need to call write() (the underlying function for fflush()) there is no guarantee that there will be a write error. My feeling is that an assertion that referred to data in the buffer would be conforming: 06(C) If the implementation supports buffered streams: When the stream pointer argument addresses a file descriptor that is closed and there is data in the buffer for the stream pointed to, then a call to fflush() returns a value of EOF and sets errno to [EBADF]. WG15 13210-92 #14: The ISO/IEC 13210:1994 has the following assertion for fflush(): 06(A) When a stream pointer argument addresses a file descriptor that is closed, then a call to fflush() returns a value of EOF and sets errno to [EBADF]. The corresponding test in the NIST PCTS 151-2 beta test suite has a test strategy as follows: fd = Zopen(path, O_RDONLY | O_CREAT, PROT_ALL); sfd = Zfdopen(fd, "r"); Zclose(fd); expecting(EOF); expecting(EBADF); Zfflush(sfd); The problem is the requirement that this strategy places that fflush() return -1 in this case when we have a read stream. Rationale: For write streams, fflush() has to be sure that any buffered data is written. For read streams, fflush() has to discard any buffer contents and adjust the current seek address. For read/write streams, fflush() has to enable a change in I/O direction. Given that in the above code fragment there is no underlying operation to perform (there isn't even a buffer, let alone any contents to ignore), there should not be a requirement to return an EBADF error. Only the C standard and 9945-1 own the rules for fflush(). There is no requirement that we can find in either that corresponds to the above. Moreover, the above would require adding an otherwise useless system call to fflush(). Think about the precedent that this would set: Theoretically, this would imply that, unless granted immunity, each stdio function would have to do test-the-file- descriptor code whenever it didn't happen to get to an underlying operation that would do the verification already. All the test assertions in 13210 are supposed to follow directly from 9945-1 statements. The assertion quoted above has no basis in POSIX.1. We recommend that this assertion not apply to read streams. WG15 response for 13210:1994 -------------------------------------------------- The interpretation for ISO/IEC 9945-1:1990 #23 applies to these requests : ISO/IEC 13210-92 #1, and ISO/IEC 13210-92 #14. Rationale for Interpretation: ----------------------------- See ISO/IEC 9945-1:1990 #23. ______________________________________________________________________ WG15 Defect Report Ref: 13210-15 Topic: abort() and SIGABRT ignore/block/caught ----------------------------------------------------------------------- 13210-9 2 #15 Class: Defect situation This has identified a difference between 13210 and 9945-1. The 13210 standard clearly states that a conforming test suite must test abort() as stated in the document, but the base standard (9945-1) indicates that such a test reflects a non-conforming implementation. This is being referred to the sponsor for consideration as a future amendment. ______________________________________________________________________ Topic: abort() and SIGABRT ignore/block/caught Relevant Sections: 8.2.3 Defect Report: ----------------------- Does a call to abort() for the cases: (1) SIGABRT signal is being ignored, (2) SIGABRT signal is being blocked, (3) SIGABRT signal is being caught and catching function returns ALWAYS terminate the calling process with SIGABRT? Discussion: The following assertions are those of Subclause 8.1.49, abort(): 03(A) A call to abort() which terminates the process with SIGABRT has the effect of a call to fclose() on every open stream. 04(A) When the SIGABRT signal is being ignored or blocked, or is being caught and the catching function returns, then a call to abort() which terminates the process with SIGABRT has the effect of a call to fclose() on every open stream. The text "which terminates" of Assertion "04" specifies, for the cases stated, that a SIGABRT may not result in the termination of the process. This is contrary to the text of ISO/IEC 9945-1:1990: Subclause B8.2.3.12: POSIX.1 intends that processing related to the abort() function will occur unless "the signal SIGABRT is being caught, and the signal handler does not return," as defined by the C standard. This processing includes at least the effect of fclose() on all open streams and the default actions defined for SIGABRT. The abort() function will override blocking or ignoring the SIGABRT signal. Catching the signal is intended to provide the application writer with a portable means to abort processing, free from possible interference from any implementation-provided library functions. Subclause 8.2.3.12: ... The C Standard {2} specifies the conditions where abort() does or does not cause process termination. ... C Standard, Subclause 4.10.4: The abort function causes abnormal program termination to occur, unless the signal SIGABRT is being caught and the signal handler does not return. ... An implementation-defined form of the status unsuccessful termination is returned to the host environment by means of the function call raise(SIGABRT). ... The abort function cannot return to its caller. The above quoted text is clear that for the cases cited in "04": (1) SIGABRT signal is being ignored, (2) SIGABRT signal is being blocked, (3) SIGABRT signal is being caught and the catching function returns. The call to abort() is required to raise the SIGABRT signal and the calling process is required to terminate. Therefore, "04" must be corrected to properly state the requirements of POSIX.1 in the format of POSIX.3.1. 04(A) When the SIGABRT signal is being ignored or blocked, or is being caught and the catching function returns, then a call to abort() terminates the process with SIGABRT and has the effect of a call to fclose() on every open stream. Testing Requirements: Test for SIGABRT signal being ignored, blocked, and being caught with the catching function returning. Assertion "03" is a restatement of the updated assertion "04" without particulars. This should now be treated as a reference assertion. R01 A call to abort() which terminates the process with SIGABRT has the effect of a call to fclose() on every open stream. [See Assertion(s) 4 in 8.1.49.2] WG15 response for 13210:1994 ----------------------------------- The test method standard clearly states that a conforming test suite must test abort() as stated in the document, but the base standard indicates that such a test reflects a non-conforming implementation. This is being referred to the sponsor for clarifying wording in the next amendment, with the suggested action being the action stated in the original text above. Rationale for Interpretation: ----------------------------- None. Editorial note for future revision of standard (not part of the interpretation) ----------------------------------------------------------------------- The correction should be made as stated in the original request above. ______________________________________________________________________ WG15 Defect Report Ref: 13210-17 Topic: tcflow -------------------------------------------------------------- 13210-9 2 #17 Classification: No change ______________________________________________________________________ Topic: tcflow Relevant Sections: 7.2.2.3.2 Defect Report: ----------------------- The ISO/IEC 13210:1994 section 7.2.2.3.2 has the following assertions. 07 A call to tcflow(fildes,TCIOFF) causes the system to transmit a STOP character, and the return value is zero. Testing Requirement(s): Test when the data transmission on the line is suspended and is not suspended. 08 A call to tcflow(fildes,TCION) causes the system to transmit a START character to restart suspended input, and the return value is zero. Testing Requirement(s): Test when the data transmission on the line is suspended and is not suspended. The problem lies in the testing requirements, for sending a STOP character when the line is already suspended, and for sending a START character when the line is not suspended. The testing requirement makes additional implementation restrictions beyond that specified in ISO/IEC POSIX 9945-1:1990. We would request that these assertions be reworded to: 07 A call to tcflow(fildes,TCIOFF) causes the system to transmit a STOP character, and the return value is zero. Testing Requirement(s): Test when the data transmission on the line is not suspended. 08 A call to tcflow(fildes,TCION) causes the system to transmit a START character to restart suspended input, and the return value is zero. Testing Requirement(s): Test when the data transmission on the line is suspended. WG15 response for 13210:1993 -------------------------------------------------- The testing requirements are correct as they are now written. They refer to suspension of output on the line. ISO/IEC 9945-1:1990 provides for programmatic flow control on terminals that use asynchronous serial data transmission through the tcflow() interface (7.2.2.2: page 146, lines 697-706). The specifications for output control (requests TCOOFF and TCOON) define a persistent state of "suspended output", such that a call to tcflow(fildes, TCOOFF) causes output to be suspended and the output stays suspended until a call is made to tcflow(fildes, TCOON). The specifications for input flow control say simply that a STOP character or a START character be sent for tcflow(fildes, TCIOFF) and tcflow(fildes, TCION), respectively. These STOP and START characters are intended to be sent to the terminal at the remote end of the line. This means that STOP or START must be transmitted whether or not output is suspended. The text of the testing requirements would be easier to understand if they referred specifically to suspension of output. Rationale for Interpretation: ----------------------------- The output to a terminal is produced by processes on the local system. Therefore, tcflow() can control suspension or resumption of output unconditionally. The case is different for input, which is generated by a remote device that is ordinarily not under the direct control of the system. For input, tcflow() sends the STOP and START characters to request that the remote device suspend or resume transmission. Note that in the descriptions of the four possible actions for tcflow() in ISO/IEC 9945-1:1990 697-706) neither the TCION nor the TCIOFF action is conditional on whether output is suspended. This means that the START and STOP characters are treated as special characters, and are not considered to be output. There is also a definite advantage to users in requiring unconditional sending of START and STOP because this is what makes it possible for an application to regain control of a terminal connection that has become confused because of flow control problems. _________________ end of SC22 N2583 _______________________________