[Bug 276220] tty_disc canonical input processing: suprising behavior of the EOF cchar

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276220

            Bug ID: 276220
           Summary: tty_disc canonical input processing: suprising
                    behavior of the EOF cchar
           Product: Base System
           Version: 14.0-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: standards
          Assignee: standards@FreeBSD.org
          Reporter: hym2209268914@gmail.com

The naive programmer, having some experience with the tty, and having read the
POSIX 2017 may assume that upon input of the EOF cchar just throws it self away
and flushes the dumb line editor's contents to the read queue.

That's not what happens in FreeBSD. If a canonical input processing program,
like cat(1), chooses to repeatedly read() with nbyte set to 5 bytes, when the
user presses 'h' 'e' 'l' 'l' 'o' '^D' successively, the read queue will be 6
bytes as reported by FIONREAD. The first read() will complete as expected,
returning 5 and decreasing read queue to 1 byte. but when it finishes echoing
the chars and read() again, the ttydisc would throw away the 1 byte in the
input queue and immediately return 0! The program would then terminate, much to
the surprise of the naive programmer.

That is, when program read() the input queue when the sole character there is
an EOF, the kernel would incorrectly return 0 rather than throw it away and
wait for input. The EOF or canonical mode should not affect the processing of
the input queue, only the dumb line editor. 

Normally read() returning 0 in canonical input processing should only happen
when user have just pressed EOF/EOL/EOL2 and pressed EOF again.

If I stop the program via debugger, hit 'hello^D', switch to -icanon via stty
-f, then continue the program, this weirdness will not happen.

The latest Linux kernel does not have this problem. 
NetBSD kernel also has this problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.