JTC1/SC22
N2583
Date: Mon, 15 Sep 1997 13:21:10 -0400 (EDT)
From: "william c. rinehuls" <rinehuls@access.digex.net>
To: sc22docs@dkuug.dk
Subject: SC22 N2583 - WG15 Record of Responses for ISO/IEC 13210 WITH LETTER BALLOT
__________________ 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 _______________________________