kern/40109: [dM] PARMRK bugs

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

        Note: There was a bad value `medium' for the field `Severity'.
        It was set to the default value of `serious'.

>Number:         40109
>Category:       kern
>Synopsis:       Buggy PARMRK treatment of \377
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Dec 05 00:55:00 +0000 2008
>Originator:     der Mouse
>Release:        -current as of tty.c,v 1.228
>Organization:
        Dis-
>Environment:
        Any 1.4T or 4.0 - probably everything in between.
>Description:
        (1) PARMRK's escaping of \377 doesn't work unless INPCK is set
        too.

        termios(4) says, of PARMRK,

                If PARMRK is set, and IGNPAR is not set, [...].  To
                avoid ambiguity in this case, if ISTRIP is not set, a
                valid character of `\377' is given to the application
                as `\377', `\377'.

        However, the code does not actually do this doubling unless
        INPCK is also set:

        } else if (c == 0377 &&
            ISSET(iflag, ISTRIP|IGNPAR|INPCK|PARMRK) == (INPCK|PARMRK)) {
                /* "Escape" a valid character of '\377'. */
                (void)putc(0377 | TTY_QUOTE, &tp->t_rawq);
                (void)putc(0377 | TTY_QUOTE, &tp->t_rawq);
                goto endcase;
        }

        I believe this is a code bug, not a doc bug, because the
        documented behaviour is more useful - an application may want
        to distinguish between a break condition and a 0x00 character
        without turning on input parity checking.  (Indeed, it was just
        such an application that led me to discover this.)

        (2) If PARMRK _does_ escape a \377, there's a good deal of
        other processing that gets bypassed, thanks to "goto endcase".
        For example, ttwakeup() and ttyecho() don't get called, so an
        isolated 0xff will mysteriously fail to wake up an application
        blocking for tty input (my application ran into this too), and
        won't get echoed even if echoing is enabled.

>How-To-Repeat:
        Write code to distinguish between breaks and 0x00, but without
        parity checking, based on the manpage.  Try it and find it's
        not working as documented - 0xff characters don't get doubled.

        Fix that bug and then find your program blocking waiting for an
        input character even when a 0xff gets sent.
>Fix:
        In progress.  Removing INPCK from its two appearances in the
        snippet quoted above fixes the no-quoting bug, but then there's
        the no-wakeup bug too.  I'm working on fixing that, but it's
        more involved - especially since it also affects input that is
        correctly framed but has incorrect parity, something that is
        (slightly) more difficult for me to test.

        I'll append to this PR when I have patches.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

>Unformatted:
        (Also present as far back as tty.c,v 1.115, probably farther.)