Subject: SC22 N2583 - WG15 Record of Responses for ISO/IEC 13210 WITH LETTER BALLOT

From: "william c. rinehuls" <[email-masked]>
Date: Mon, 15 Sep 1997 13:21:10 -0400 (EDT)

__________________ 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:  [email-masked]

_____________ 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 _______________________________