This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] termios: non-standard baudrates are not handled properly on Linux-systems (BZ#10339)
- From: "H. Peter Anvin" <hpa at zytor dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Cc: Rich Felker <dalias at libc dot org>
- Date: Wed, 3 Oct 2018 15:14:32 -0700
- Subject: Re: [RFC] termios: non-standard baudrates are not handled properly on Linux-systems (BZ#10339)
- References: <email@example.com>
On 10/03/18 12:47, Adhemerval Zanella wrote:
> As I replied, potentially program breakage is unacceptable so I see current two
> possible way to fix it:
> 1. Change Bnnn constants on Linux to match termios2 expected values, add
> compatibility symbols for old semantic, and implement new termios
> functions based on termios2 kernel abi. cf*speed might accept arbitrary
> values and we can accommodate new POSIX Bnnn value by mapping directly its
> integer value.
> The drawback is potentially breakage of non-compliant programs which set
> the speed direct on termios instead of using POSIX cf*speed API.
Well, the problem is also if an old application passes an old speed_t
value to the new API functions or gets one back. This problem can be
minimized, if not completely eliminated, by symbol versioning.
The direct mucking with c_cflags will actually "just continue" to work
for existing binary applications. For future *source* applications, this
should be (mostly) preventable by not exporting the CBAUD and CBAUDEX
constants to userspace.
None of this, of course, solves the problem of letting the programmer
assert, in a portable application, that "no, really, the baud rate
functions take arbitrary integers." In one of my own projects I ended
up building a really ugly autoconf test for it.
> 2. Implement a new API to return the line speed in the termios as bits per
> second, and implement termios functions based on Linux termios2 kernel ABI.
> Bxxx functions will continue to have legacy values, not breaking non-portable
> application which may rely on it.
> The drawback is would be initially a GNU extension (so another glibc
> idiosyncrasy) and it might conflict with possible POSIX extension if it
> where proposed for inclusion.
> Hans Peter Anvin is advocating for second options , with the new API as:
> -- Function: speed_t cfgetispeedbps (struct termios *TERMIOS-P)
> This function returns the input line speed stored in the
> structure `*TERMIOS-P' as a number of bits per second.
> Initially I was trying to avoid adding a glibc specific implementation, but
> after reading the bug reports I am more inclined that the new ABI, along with
> refactor Linux termios implementation to use termios2 kernel abi, and working
> to add this on POSIX.
> Any thoughts about it?
>  https://sourceware.org/bugzilla/show_bug.cgi?id=10339
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683826
Standardization does have a chicken-and-egg problem, but there is always
the option to query the POSIX committee. FreeBSD and Windows(!) already
define their symbolic constants as just the corresponding integer.
One of the nice things about having an entirely new entrypoint is that
legacy implementations can be wrapped in an extremely simple library
(which, of course, doesn't address the limited functionality, but there
is no solving that problem.) Producing that library isn't possible in a
strictly conforming portable manner, but can in practice be done easily
Here is a simple tool which can create such a wrapper, making use of
"gcc -E -Wp,-dM" to find the macros: