Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!darwin.sura.net!sgiblab!majipoor.cygnus.com!kithrup.com!sef
From: sef@kithrup.com (Sean Eric Fagan)
Subject: Re: termios IEXTEN broken? (^V^D == ^D or nothing)
Organization: Kithrup Enterprises, Ltd.
References: <almC6G4G8.6vp@netcom.com>
Message-ID: <C6Iqt6.2LB@kithrup.com>
Date: Tue, 4 May 1993 20:12:27 GMT
Lines: 39
In article <almC6G4G8.6vp@netcom.com> alm@netcom.com (Andrew Moore) writes:
>When reading terminal input in line-discipline mode (ICANON | IEXTEN),
>the EOF character (^D) is not properly treated when preceded by the
>LNEXT character (^V).
This is a definite bug, and is only present in the jolitz-derived
systems. *sigh* (It might be fixed in 0.2, but that doesn't help much
right now :).)
The problem comes from this:
/*
* Check for literal nexting very first
*/
if (tp->t_state&TS_LNCH) {
c |= TTY_QUOTE;
tp->t_state &= ~TS_LNCH;
}
(this code is executed after the LNEXT character is processed).
TTY_QUOTE, if I remember correctly, is 0x100. So, assuming a VEOF
of 0x04 (control-d), 'c' is now 0x104. However, when it gets
stuffed into the ring buffer, we see that:
struct ringb {
char *rb_hd; /* head of buffer segment to be read */
char *rb_tl; /* tail of buffer segment to be written */
char rb_buf[RBSZ]; /* segment contents */
};
the array consists of char's, not short's, and a 0x104 stuffed into
a char is 0x04 -- and so the rest of the code (ttread(), actually)
cannot distinguish it from a normal EOF character.
A fix ("the" fix?) would be to change the array, and everything
associated with it, to use short's, instead of char's; I haven't done
that because it is a non-trivial amount of work, and getting it wrong
will break your system horribly.