This is the mail archive of the
libc-alpha@sourceware.org
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: Paul Eggert <eggert at cs dot ucla dot edu>, 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:13:26 -0700
- Subject: Re: [RFC] termios: non-standard baudrates are not handled properly on Linux-systems (BZ#10339)
- References: <f247bd97-41fa-ceaf-eb0a-f83349513b13@linaro.org> <91fe1328-e729-3b18-13eb-8a0acfcae393@cs.ucla.edu>
On 10/03/18 15:01, Paul Eggert wrote:
> On 10/3/18 12:47 PM, Adhemerval Zanella wrote:
>> Hans Peter Anvin is advocating for second options [2], 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.
>
>
> speed_t is unsigned int. Is that enough for all devices likely in the
> reasonably-near future? I see stories about Arduino serial ports running
> at multiple Mb/s, and although that fits it's getting uncomfortably
> close to UINT_MAX. USB 3.0 can in theory do 5 Gb/s, which would exceed
> 'unsigned int' range, and USB 3.1 and 3.2 are even faster.
>
speed_t might be 16 bits on some (non-glibc) platforms as far as we know.
-hpa