[musl] ioctl signature

[musl] ioctl signature

[Rafael Ávila de Espíndola]

The signature of ioctl in musl is

int ioctl (int, int, ...);

In glibc it is

int ioctl(int fd, unsigned long request, ...);

The requests are always 32 bits, and the most significant bit is used to
indicated that this ioctl is a read operation. This means that some
constants are negative numbers if using an int. I have noticed this
because rust's interface to libc matches the system libc implementation,
and in alpine I got an error for a literal out of range for
0xc0104801. I don't know if a C compiler would produce a warning, but
that seems somewhat reasonable.

Should the declaration be changed to use an unsigned request?:

int ioctl (int, unsigned int, ...);

Thanks,
Rafael

Re: [musl] ioctl signature

[Rich Felker]

On Fri, May 24, 2024 at 05:03:59PM +0000, Rafael Ávila de Espíndola wrote:
> The signature of ioctl in musl is
> 
> int ioctl (int, int, ...);
> 
> In glibc it is
> 
> int ioctl(int fd, unsigned long request, ...);
> 
> The requests are always 32 bits, and the most significant bit is used to
> indicated that this ioctl is a read operation. This means that some
> constants are negative numbers if using an int. I have noticed this
> because rust's interface to libc matches the system libc implementation,
> and in alpine I got an error for a literal out of range for
> 0xc0104801. I don't know if a C compiler would produce a warning, but
> that seems somewhat reasonable.
> 
> Should the declaration be changed to use an unsigned request?:
> 
> int ioctl (int, unsigned int, ...);

The declaration matches the POSIX definition of the ioctl interface,
which is obsolete but the relevant historical standard. From a C
standpoint it doesn't really matter whether the argument is signed or
unsigned since either way the value round-trips right.

I think we explored trying to make the constants come out as signed to
match the interface, but there were reasons that didn't work well
either.

Rich