WG15 Defect Report Ref: 9945-1-48
Topic: last close() on terminal

This is an approved interpretation of 9945-1:1990.


Last update: 1997-05-20

                                                                9945-1-90 #48

	Topic:			last close() on terminal
	Relevant Sections:
	Classification:		No change.

Defect Report:

       +Interpretation Request ref     : VWG/005/063092
       [Problem	description]
	      last close() on terminal

       [Request	text starts]
       POSIX.1:1990 section Closing a Terminal	Device file states:
	   The last process to close a terminal	device file shall
	   cause any output to be sent to the device and any input
	   to be discarded.

       Is it required behaviour	that in	the case that output has
       previously been suspended by a call to tcflow(),	that the
       close() will allow output to be restarted or is it
       permissible behaviour for the data to be	discarded?

       X/Open proposes that close() will allow output to be
       restarted.  [text ends]


WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)

The standard does not specify that a close() on a terminal device file
include the equivalent of a call to tcflow(fd,TCOON). The language
of allows, but does not require such an action.

An implementation that discards output at the time the close() is called,
after reporting in the return value to the write() call that the
data was written does not conform to POSIX.1.

Rationale for Interpretation:

Section clearly allows for some buffering to occur on terminal
output, but the standard leaves unspecified the detailed behavior
of this buffering and its interaction with program-directed flow
control (tcflow()) and externally generated flow control.  It is worth
reiterating that an application has functions such as tcdrain(),
tcflush(), and tcflow() available to obtain the detailed behavior it

At the time of last close() on a terminal device, an application
relinquishes any ability to exert flow control via tcflow().  Contrary
to B., the implementation is never permitted to "cause a flush
of pending output", if "flush" is taken to mean "discard".  In the
situation described, the two options are "resume output and wait for
it to drain" and "block (until interrupted by a signal)".  External
flow control could cause the first option to degenerate into the
second.  One overall intent is that a naive program can have its
output directed to a terminal device without danger of truncation from
close() being called immediately after successful return from the last