On June 17, 2025 3:10:52 PM PDT, "Pádraig Brady" <p...@draigbrady.com> wrote:
>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
>

It's a bit odd that it is accepted if speed_t is unsigned int, though. I did 
put in a check for that, but perhaps I got the casting rules wrong.

One more thing: *if* the macro __MAX_BAUD is defined, it normally should 
contain the maximum permitted value of speed_t. I just don't know how universal 
that is...

Reply via email to