speed_t on Hurd (POSIX violation)

[H. Peter Anvin]

On May 12, 2025 3:28:51 PM PDT, Samuel Thibault <samuel.thibault@aquilenet.fr> wrote:
>H. Peter Anvin, le lun. 12 mai 2025 15:24:45 -0700, a ecrit:
>> On May 12, 2025 3:11:43 PM PDT, Samuel Thibault <samuel.thibault@aquilenet.fr> wrote:
>> >H. Peter Anvin, le lun. 12 mai 2025 14:49:27 -0700, a ecrit:
>> >> On 5/12/25 14:06, Samuel Thibault wrote:
>> >> > > The above types shall be all unsigned integer types.
>> >> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >> > > 
>> >> > > Should this be fixed
>> >> > 
>> >> > Yes we should fix this.
>> >> > 
>> >> > > (possibly including a range check if the kernel interface doesn't
>> >> > > support values above INT_MAX)?
>> >> > 
>> >> > The RPC interface just uses the speed_t type actually.
>> >> 
>> >> As in it picks up speed_t from glibc?
>> >
>> >Yes.
>> 
>> Another question: should the speed_t constants be explicitly unsigned?
>
>I don't know when that would really make a difference below 2^32,
>perhaps in speed comparison conditions?
>
>Samuel

Yeah, possibly. I just don't know what the policy is supposed to be.