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)
On 10/09/18 10:48, Paul Eggert wrote:
> H. Peter Anvin wrote:
>> In other words, B300
>> == 7, so 7 baud would be represented by the value 300.
> I'm afraid I'm confused by this use of "baud_t" and "7 baud". A baud is
> one symbol per second, which in general differs from one bit per second.
> Still, if 7 baud corresponds to 300 bits per second, I'm having trouble
> seeing what's going on. I guess you mean that a speed_t value equal to
> B300 corresponds to a baud_t value equal to 300, but I could well be wrong.
> I suggest giving the new type a name other than "baud_t" to avoid this
> sort of confusion. "bps_t" or "bits_per_second_t" would be better.
We are talking about *serial ports* here, real or simulated (if one has
a problem with that, consider that we don't have teletypes either these
The existing, legacy terminology for serial ports is "baud", and
arguably the bps rate for an asynchronous port is *less* than its baud
rate. Consider e.g. the legacy flag name CBAUD.
Furthermore, it is less likely to cause a namespace collision exactly
for this reason.
>> Now, assuming we really want to support baud rates over 4 Gbps, I'm
>> of an interface which might amount to a 5:27 floating point number. no
>> bit, and biased for integers only.
> Why not use 'float' or 'double' for this? No sense reinventing the
> floating-point wheel.
1. The precision is less and the exponent far bigger than necessary;
2. Two sign bits are wasted: one for the mantissa, one for the exponent;
3. Idea is such that it identity-maps numbers up to 2^28-1 with
integers, for compatiblity.
4. At least for Linux, using the FPU in the kernel is a no-no.
I should have clarified that I was talking about speed_t here, not
baud_t, though. My assumption was that baud_t would be a 64-bit integer.