possible bug in tip's handling of parity

[Phil Ngai]

In looking at the way tip handles parity I see that it computes the
parity of each character itself depending on the value of an internal
variable which can be "even", "odd", "none", "zero", and "one".
Obviously the tty driver must send eight-bit data so that tip's
careful work is not undone.

This is all fine and well but there are more characters sent than
those that pass through tip. In particular, if tandem mode is set the
XOFF/XON characters used for flow control are generated directly by
the tty driver. Since it thinks it should send eight-bit data, the
XOFF/XON characters generated can come out with a parity inconsistent
with what tip thinks it is sending.

If you are connected to a network which requires even parity in all
characters, even XOFF/XON, then XOFF does not seem to work.

Comments, please?
-- 
 Even lefties have rights!

 Phil Ngai +1 408 749-5720
 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
 ARPA: amdcad!phil at decwrl.dec.com