[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240524171018.GE10433@brightrain.aerifal.cx>
Date: Fri, 24 May 2024 13:10:18 -0400
From: Rich Felker <dalias@...c.org>
To: Rafael Ávila de Espíndola <rafael@...indo.la>
Cc: musl@...ts.openwall.com
Subject: Re: ioctl signature
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
