[Bug libc/10339] Terminal interface: non-standard baudrates are not handled properly on Linux-systems

["hpa at zytor dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=10339

--- Comment #11 from hpa at zytor dot com <hpa at zytor dot com> ---
On October 3, 2018 12:33:12 PM PDT, "adhemerval.zanella at linaro dot org"
<sourceware-bugzilla@sourceware.org> wrote:
>https://sourceware.org/bugzilla/show_bug.cgi?id=10339
>
>--- Comment #9 from Adhemerval Zanella <adhemerval.zanella at linaro
>dot org> ---
>> However, actually, this does not work as described.  cfgetspeed
>> returns a traditional B9600 value, not the number 9600 (or whatever).
>> (cfsetspeed does accept baud rates in bps as documented and converts
>> them to magic constants in the struct termios).
>
>> The only way to make this work as documented in the glibc manual
>would
>> be to change the Bnnnn #defines each to have the value nnnn.  That
>> would break compatibility with programs which know about setting
>> c_cflags&CBAUD to Bnnnn.  (I think such programs will exist.)
>
>And these programs are not portable if they are setting the speed
>by themselves instead of using POSIX defined cf*speed functions.
>
>> I therefore suggest that the specification is wrong.  cfget{i,o}speed
>> are defined in POSIX to return these Bnnnn constants, and the values
>> of the constants can't be changed, so users of cfget{i,o} speed will
>> never be able to expect speeds.  cfgetispeed and cfgetospeed have to
>> continue to return magic constants rather than baud rates.
>
>We do have an option to change Bnnn constans, but it in incur in
>tradeoffs.  So the options we have are:
>
>  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 accomodate 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.
>
>  2. Implement a new ABI 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.
>
>There were previous cases where we kept binary semantic for old 
>binaries, but removed non-conformant usage in favor of POSIX semantic.
>However I am not sure if it worth the potential breakage, specially
>on API that has not been changed for some time.
>
>Could I bring this up to libc-alpha so we check which other developers 
>the best course of action?

Please do.

-- 
You are receiving this mail because:
You are on the CC list for the bug.