Use of the information contained in this unapproved document is at your own risk
.Last update: 10 April,2001
1003.1-90 #81
_____________________________________________________________________________
Interpretation Number: XXXX
Topic:
Relevant Sections: 7.2.1.2
Interpretation Request: (Defect Report)
-----------------------
Date: Sat, 22 Feb 1997 10:33:17 -0800
Dear Standards Board:
I would like to request an official, binding interpretation
from the IEEE concerning the following point in subclause
7.2.1.2 of IEEE Std 1003.1-1990 (POSIX.1; unchanged in
1003.1-1996):
Does POSIX.1 require that tcsetattr(fildes, TCSANOW,
termios_p) preserve data that may have been received by the
serial communications port but not yet processed and placed
in the input queue?
My reading of the Standard is that POSIX.1 is silent as to
whether the data are preserved. This means that the effect
on unprocessed input is unspecified, so a conforming
implementation can discard the data.
The critical specifications are:
(1) If optional_actions is TCSANOW, the change shall
occur immediately.
(2) If optional_actions is TCSADRAIN, the change
shall occur after all output written to fildes
has been transmitted. This function should be
used when changing parameters that affect output.
(3) If optional_actions is TCSAFLUSH, the change
shall occur after all output written to the
object referred to by fildes has been
transmitted, and all input that has been
received, but not read, shall be discarded before
the change is made.
(1002.1-1990 p. 143, 144; subclause 7.2.1.2)
(Questions in the elaboration below are meant to be
rhetorical. They are not meant to request specific
interpretations.)
The descriptions focus largely on output. This is because
output is under the system's control to a much greater
extent than is input. The description of tcflow(), for
example, has a corresponding asymmetry, in that the system
is required to directly control output flow but only to send
START and STOP out on the serial line to request that the
remote system control input flow.
Consider the case of a serial port that has an input buffer
that holds raw input, to await processing in batches. This
is an attractive architecture because it can greatly reduce
the number of interrupts needed to service input on the
port.
What should happen to this buffered raw input when
tcsetattr(fildes, TCSANOW, termios_p) is called? If the
newly-set parameters include any changes to the input
processing mode, the result of input processing on a system
with such buffers could be different from what would be
placed in the input queue by an implementation that does not
buffer unprocessed data.
Things are even worse for a character that has been only
partly received from the transmission line by the serial
hardware when the interface is reset. There is no unique
correct way to process such data, and in many situations the
data will be irretrievably corrupted.
My feeling is that the TCSANOW optional action means "Make
the change right now, no matter what happens to the data in
transit". Tools are provided to allow the programmer to
trade responsiveness for data integrity for output data. No
such facilities and no corresponding guarantees are provided
for input, because the problem is fundamentally difficult.
It's impossible for the system to know what is about to
arrive from the incoming serial connection.
Thank you for your attention to this issue.
Interpretation response
------------------------
The standard is silent on this issue, as to whether
the data are preserved , and as such no
conformance distinction can be made between different
implementations.
Rationale
-------------
None.
Forwarded to Interpretations group: 23 Feb 1997
Proposed resolution: 15 October 1997
Finalised: 18 November 1997