Re: [PATCH 1/1] stty: arbitrary or non-a priori known speed_t support

[Pádraig Brady]

On 17/06/2025 20:07, H. Peter Anvin wrote:
> On June 17, 2025 5:58:48 AM PDT, "Pádraig Brady" <P@draigBrady.com> wrote:
> > 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
>
> Yes, that will succeed with glibc 2.42+, as will split speed.
>
> The most straightforward way to test would of course be to have a test program 
> that does an explicit tcgetattr, but otherwise I think the answer is you should 
> either get back what you set or get an error.

Given that the system can now potentially accept any value,
I think what I'll do is create a follow up patch to LD_PRELOAD a cfsetispeed
that always returns -1, to verify we error for that.
> If you think it would be useful, it would not be hard to add an option to list 
> the enumerated speeds or show the range of speeds that can be represented in a 
> speed_t.
That would probably be overkill, given potentially anything is accepted.

Talking about range though,
I'm thinking we should explicitly disallow negative values?
Currently (on 64 bit) the following is equivalent to 9600 which is just 
confusing I think:

  stty ispeed '-18446744073709542016'

Note the current code clamps overflow values to ULONG_MAX,
passing that down for the lower layers to validate.
That's probably OK to leave as is.

I'll make that negative check adjustment also before pushing unless I hear 
otherwise.

cheers,
Pádraig