On 17/06/2025 00:00, Pádraig Brady wrote:
On 16/06/2025 22:58, H. Peter Anvin wrote:
Support the case where speed_t is simply a number, and in that case
assume that arbitrary values can be passed. This is assumed to be the
case when all known speed_t macros equal their own value.
Try to probe for a variety of speed_t constants by trying to coax
$(CC) into emitting macro definitions (-E -dM). If this is not
supported, use a fairly extensive list of constants as a
fallback. This both improves the test for arbitrary speed support, as
well as allowing proper operation in the case where the constants are
not plain numbers and allows for handing enumerated speed constants
that were not known a priori when the source code was written.
A simple shell script (mostly using sed) is used to turn the list of
constants (probed and predefined) into a pair of conversion functions,
baud_to_value() and value_to_baud(); string_to_baud() is then
reimplemented as a wrapper around the latter. Using a shell script
hopefully should make this portable.
This looks good from a quick look.
I'll give it a more thorough review tomorrow.
Note we avoid TAB chars, but I've fixed that up locally,
so no need to resend just for that.
I'll also add a NEWS entry for the change.
We'll need to adjust tests a bit.
Currently we check that `stty ispeed 420` fails,
though I'm guessing that this may now succeed with glibc >= 2.42?
Do you have any ideas on how to test this?Note we can distinguish the
TERMIOS_SPEED_T_SANE valuethough `stty ispeed 420` returning "invalid ispeed".
cheers,
Pádraig
