Problems while using divecomputer-simulator for linux

[Linus Torvalds]

Yes indeed, this seems to be a Fedora "feature".

There's a Fedora-specific insane patch:

  glibc-fedora-linux-tcsetattr.patch

that explicitly adds that completely insane check for no good reason,
and has this moronic comment:

+      /* The Linux kernel has a bug which silently ignore the invalid
+        c_cflag on pty. We have to check it here. */

because the kernel is *right* to silently ignore bits like that that
don't make sense, and it looks like the idiotic Fedora patch actively
tries to break this whole concept.

Adding Jeff and Jakub to the participants list, because I can't make
heads or tails of the Fedora glibc package history, because it seems
to be very messy. The patch seems to have come into the fedora glibc
package git tree in commit c7aa529bd29880da55414efcf317319c8dd790e0,
which says

  Author: Jakub Jelinek <jakub at fedoraproject.org>
  Date:   Sat Sep 25 08:23:12 2004 +0000

    auto-import glibc-2.3.3-57 on branch devel from glibc-2.3.3-57.src.rpm

but the actual change is not listed in the ChangeLog, so I really
don't know who to blame.

Jeff, Jakub: the whole point is to allow people to use pty's instead
of "real" tty's, so erroring out when you set bits that don't make
sense for a pty is _exactly_ the wrong thing to do, and is the reason
why the Linux kernel silently ignores those bits.

Your glibc patch (that hasn't been accepted upstream, because
apparently saner people existed there) is stupid and pointless. In
fact, it makes me think that in order to *avoid* your idiotic patch,
the kernel should now stop changing termios, and just silently ignore
those bits - which would just hide the fact that the kernel ignores
those bits better. But WHY THE F*CK DOES GLIBC CARE? The kernel tries
to be *nice* and show that those bits don't make sense for a pty, but
glibc then takes that "nice" and screws things up on purpose.

Can you please hunt down whoever did this, and try to figure out why
that idiotic patch exists? And perhaps slip some slow-acting and
painful poison in their coffee? Or at least make sure they don't
reproduce?

Quoting my previous email for history (not cleaned up, I should have
done more editing)/

                   Linus

On Sun, Mar 30, 2014 at 12:52 PM, Linus Torvalds
<torvalds at linux-foundation.org> wrote:
> On Sun, Mar 30, 2014 at 12:14 PM, Venkatesh Shukla IIT BHU
> <venkatesh.shukla.eee11 at iitbhu.ac.in> wrote:
>>
>> I have done as you asked. The output is here : http://pastebin.com/E50ayiSs
>>
>> I have recently shifted to Fedora 20. It worked in Ubuntu earlier.
>
> It does indeed look like some glibc idiocy. Sometimes I wonder what
> the f*ck is wrong with libc people.
>
> The kernel didn't actually complain at all, and what seems to happen
> is that glibc tries to be "helpful", and after it has done the TCSETC
> it does a TCGETC and compares the result. And notices that the PARENB
>
> And it looks like it notices that it tried to *set* c_cflags to 0xfbb
> but then it reads back c_cflags as 0xebb.
>
> The difference is octal 0400, which is PARENB. Because under Linux,
> pty's always do
>
>         tty->termios.c_cflag &= ~(CSIZE | PARENB);
>         tty->termios.c_cflag |= (CS8 | CREAD);
>
> and glibc tries to be "helpful" and notice that some of the settings
> don't stick. For no good reason.
>
> Now, I'm not saying that the kernel necessarily has to do the above
> for pty's (it could just ignore the bits, and not set them to what
> pty's actually do), but Linux has always done the above, so it's some
> idiotic change in glibc that now causes problems.
>
> Don't ask me why the glibc people decided to "improve" on tcsetattr() this way.
>
> Funnily enough, I do *not* find this in the glibc sources for
> tcsetattr (sysdeps/unix/sysv/linux/tcsetattr.c):
>
>   https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/tcsetattr.c
>
> so I wonder if this is some Fedora "feature".
>
>              Linus