[Bug 219098] New: Termios man page description of semantics of MIN, TIME

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=219098

            Bug ID: 219098
           Summary: Termios man page description of semantics of MIN, TIME
           Product: Documentation
           Version: unspecified
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: man-pages
          Assignee: documentation_man-pages@kernel-bugs.osdl.org
          Reporter: stewart.weiss@acm.org
        Regression: No

The current version of the termios(3) man page states,
"MIN > 0, TIME == 0 (blocking read)
              read(2) blocks until MIN bytes are available, and returns
              up to the number of bytes requested.
".

This used to be true but it no longer true. The case it does not cover is
when the number of bytes requested is less than MIN. In this case read(2) is
unblocked as soon as the number of bytes in the tty's line discipline is
at least the number of bytes requested, even if it is less than MIN.
The n_tty_read() function's while loop breaks when this is true.

If I c_cc[VMIN] = 3, c_cc[VTIME] = 0 and disable icanon in the driver and
then run a program such as:

int main( int argc, char *argv[] )
{
    char inbuf;

    while( read(STDIN_FILENO, &inbuf, 1) > 0  ) {
        if ( -1 == write( 1, &inbuf, 1 ))
             exit(1);
    }
    exit(EXIT_SUCCESS);
}

the call to read() will return after each character. 
Shouldn't the correct description be:

"MIN > 0, TIME == 0 (blocking read)
              If MIN is less than or equal to the number of bytes requested, 
              read(2) blocks until MIN bytes are available, and returns
              up to the number of bytes requested. If MIN is greater than
              the number of bytes requested, read(2) is unblocked as soon
              as the number of bytes requested is available, regardless of
              the value of MIN.
"

My apologies if this is the wrong category for this bug report.
I should add that this behavior was not true back in 2012, when I would
teach it to my students. Then, it did behave as the current man page describes.
".

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.