Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hpfcdc!hpfcmr!hpfcse!hpupnja!markf
From: markf@hpupnja.HP.COM (Mark Fresolone)
Newsgroups: comp.sys.hp
Subject: Re: buggy hp9000/800 3.01 code?
Message-ID: <220010@hpupnja.HP.COM>
Date: 2 Apr 89 09:10:18 GMT
References: <659@kcdev.UUCP>
Organization: HP Piscataway, NJ
Lines: 74

>Steve Fullerton
>>A few words to the wise on possible nasty bugs in the 3.01 release of 
>>HP9000/850 UNIX.
>I have encountered another curious problem, anomaly, bug, with the
>HP-UX 3.0 release. ...  >What we are doing is setting termio to raw and
>reading characters 1 at >a time. ...

As I understand it, the change in non-canonical processing for the VMIN>0,
VTIME>0 case was made quite intentionally, to better conform with the specs.
Aparently, VMIN was never intended to be used with reads of less than VMIN
characters.

>  1) Issue the read
>  2) User enters a character, it is read and all is fine, go to 1)

The scenario in steps 1 and 2 is this: at the first read, the initial timeout
is infinite.  When the first character is received, the read is still not
satisfied (neither VMIN=5 nor VTIME, which has not been started, is satisfied.
Of course, one can argue that the read() is satisfied if not the line disci-
pline...  You see the ambiguity.)  Anyhow, after this character is received,
the intercharacter timer is started (2 x 0.10 seconds, in your case).  For
normal keystrokes, this timer expires before the next character is received by
the LD, and for THIS reason, the read(,,1) returns the one character.

>  3) User enters a cursor key so the read returns an ESC, issue another read
>  4) This second read blocks waiting for input.  When a key is
>     pressed, the second character from the cursor key is what >     is read.
>  5) Subsequent reads remain out-of-sync; i.e., when a character is
>     entered, the previous entry is what is read.

Perhaps you can guess what happens when a cursor control key is pressed.  Both
characters are received by the LD, but the read is not satisfied yet as far as
VMIN/VTIME are concerned.  A fifth of a second later, the LD times out, and
proceeds to give the user program just what it asked for - one of the two
characters.  For the next read, the initial timeout begins as infinite
(arguable, perhaps, since one might expect it to treat the queued character as
"just received", and kick off the intercharacter timer).  The LD waits for the
"first character received".  When this (second) character is received, the
timer starts, causing the queued character to be copied to user space when it
expires.

>.. He suggests >termio.c_cc[VMIN] = 5 and termio.c_cc[VTIME] = 2. ...
>I was> finally able to get it to work by setting the VMIN value to 1 and the
>VTIME value to 0.

This is the most common "workaround" for this new behavior.  One might consider
whether this, or [ VMIN=0, VTIME>0 ], is not the behavior you wanted in the
first place.  [ VMIN>0, VTIME>0 ] is generally used for burst mode.  By the
way, while Mr. Rochkind does not show the cooperating read() for setraw() in
Sec. 4.5, in his use of non-canonical mode in Sec. 4.4.8, he goes so far as
to set VMIN explicitly as:

	" tbuf.c_cc[4] = sizeof(buf);  /* MIN */ "

where he later uses:

	" switch (total = read(0, buf, sizeof(buf))) { "

What I find interesting about his non-canonical examples is that in Sec. 8.7,
he sets VMIN = VTIME = 0, in a program where he wishes to time a read using
alarm() (see top paragraph on p. 224).  It appears, however, that he might
end up with quite a few "Mysterious EOF"s!  I have not tried it.

>I am confident in the code---it has been ported to all major UN*X systems
>and even worked fine for HP-UX 2.0x as well as on HP9000/3xx 6.x systems.
>So something is really wrong and programs doing screen handling might
>have a big surprise when moving to 3.0.

Many machines and programs use the pre-3.01 behavior, where the read size is
less than VMIN, and I have a feeling we have not heard the last of this.

Mark Fresolone
HP Systems Engineer
These opinions are solely mine, and not necessarily those of my employer...