Xref: utzoo comp.unix.wizards:11050 comp.bugs.sys5:549
Path: utzoo!attcan!uunet!husc6!bloom-beacon!gatech!rutgers!ucsd!ames!amdahl!pyramid!prls!philabs!ttidca!mb
From: mb@ttidca.TTI.COM (Michael Bloom)
Newsgroups: comp.unix.wizards,comp.bugs.sys5
Subject: termio TCSETAF bug
Summary: driver code does not match man page. Which is correct?
Message-ID: <3158@ttidca.TTI.COM>
Date: 10 Sep 88 01:18:35 GMT
Reply-To: mb@ttidca.tti.com (Michael Bloom)
Organization: Citicorp/TTI, Santa Monica
Lines: 31

The man page for TERMIO(7) states that TCSETAF flushes the input queue
after waiting for output to drain.

In fact, in s5 rel 3.0, it's doing a ttyflush(tp,FREAD|FWRITE), flushing
both input AND output.

Harmless, you say, since it's already waited for output to drain? 

Not so.  I discovered this after adding packet mode to the pty driver
on my system to support remote flushing. Afterward, the bug displayed
itself quite graphically. While rlogined, every time emacs called it's
internal error handler, i.e to report an invalid command, the screen
would go haywire.

This turned out to be due to emacs's use of TCSETAF to flush terminal
input on user error.  The flush (both input and OUTPUT) was being
propagated out of band to the rlogin client, which dutifully flushed
output smack in the middle of a set of terminal escape sequences which
were only now being displayed.

Admittedly, TCFLSH would have been a better choice for emacs to have used,
but given the current termio documentation, the use of TCSETAF was not
unreasonable. For the time being, i've modified emacs to use TCFLSH.

So, now two questions.

First, is this a bug in the documentation or in the tty code?

Second, noting that the SunOs 4.0 manual page is identical in this
regard to the sys5 manual page, does TCSETAF behavior in the new Sun
tty driver follow the man page or the original sys5 code?