Xref: utzoo comp.unix.questions:23943 comp.unix.wizards:22993 comp.unix.xenix:12498 comp.unix.i386:7078
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.unix.xenix,comp.unix.i386
Subject: Re: TTY line discipline
Message-ID: <3716@auspex.auspex.com>
Date: 22 Jul 90 01:39:43 GMT
References: <2026@beam.UUCP>
Followup-To: comp.unix.i386
Organization: Auspex Systems, Santa Clara
Lines: 44

>The symptoms are as follows: using the standard (and only?) line
>discipline, the following termio settings had a strange side effect:
>
>    n_ctrl.c_iflag &= ~(INLCR | IGNCR | ICRNL | IUCLC );
>    n_ctrl.c_iflag |= IXOFF;
>    n_ctrl.c_lflag &= ~(ICANON | ISIG);
>    n_ctrl.c_cc[VINTR] = 255;   /*  these seem to disable ...  */
>    n_ctrl.c_cc[VQUIT] = 255;   /*  ...                        */
>    n_ctrl.c_cc[VERASE] = 255;  /*  ...                        */
>    n_ctrl.c_cc[VKILL] = 255;   /*  ... the relevant function  */

Yes, but so does turning ICANON and ISIG off; you can leave VINTR and
VQUIT alone if you turn ISIG off, and leave VERASE and VKIL alone if you
turn ICANON off.

Also, "seem to" is the relevant part.  In the vanilla S5R[123] driver,
setting a control character to 255 sets it to 255, rather than disabling
it.  If the characters coming in are 7-bit characters (e.g., if ISTRIP is
set, or if the character size is 7 bits), it does, in effect, disable
it; however, 255 is the code in ISO Latin Alphabet #1 for the "y with a
diaresis" character, and if the characters coming in are 8-bit ISO Latin
1 characters, somebody might type that character....

(In S5R4, I think you set the character to 0 to disable it, and that
*really* disables it - i.e., a NUL coming in doesn't get treated as a
special character.)

>    n_ctrl.c_cc[VMIN] = 1;      /*  character count         */
>    n_ctrl.c_cc[VTIME] = 50;    /*  time limit              */
>
>that is, a null character on input would trigger the timeout
>condition.

Those settings shouldn't cause "null characters", if by that you mean
NUL characters, i.e. a character with the code value 0, to do anything
different from any other characters (well, not counting ^S and ^Q, which
you haven't disabled). 

>As a result, the null is swallowed by the line discipline
>and cannot be received.

That's a bug, for sure.  If it's intentional, the bug is that the person
whose intent it was (i.e., the person who introduced that bug into the
tty driver) doesn't understnand the "termio" interface....