From owner-freebsd-bugs  Tue Feb 11 01:22:46 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id BAA10438
          for bugs-outgoing; Tue, 11 Feb 1997 01:22:46 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA10428
          for <freebsd-bugs@freefall.freebsd.org>; Tue, 11 Feb 1997 01:22:41 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id UAA13503; Tue, 11 Feb 1997 20:07:38 +1100
Date: Tue, 11 Feb 1997 20:07:38 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199702110907.UAA13503@godzilla.zeta.org.au>
To: freebsd-bugs@freefall.freebsd.org, jmg@nike.efn.org
Subject: Re: bin/174 stty doesn't give very good output on error...
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

[ stty -f /dev/cua00 76800 ]

> the bug can't be fixed unless there is some restructuring of stty... and
> this probably shouldn't happen...  

Another problem is that according to POSIX.1, success of tcsetattr()
doesn't mean that all the attributes were set.  It means that at least
one attribute was set, and that other attributes were set if the system
supports them.  Perhaps the best way to fix this is to fix tcsettattr()
in all drivers to succeed if at least one attribute could be set, so
that an unsupported speed is never fatal (it's always possible to set
a non-hardware attribute like OPOST to any value, so one attribute can
always be set :-).  stty.c could then check which attributes were set.
It probably should do this anyway.

Bruce