Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.