This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [WIP] BZ #14361: POSIX vs. BSD and the `ioctl' interface.


Hello,

(7/24/12 10:34 AM), Joseph S. Myers wrote:
> On Mon, 23 Jul 2012, Carlos O'Donell wrote:
> 
>> (b) Backwards compatibility with an interface that has been around
>>     since 1993.
>>
>> Can we somehow juggle (a) and (b)?
>>
>> Comments?
> 
> The binary compatibility issue is that the code needs to work with 
> existing binaries passing "unsigned long" values.
> 
> In most cases, ioctl is coming from syscalls.list and so the value from 
> the user's code just gets passed straight through to the kernel, both 
> before and after this patch, and no binary compatibility issue arises.  
> But where ioctl is implemented in C, you need to make sure there is no 
> issue with a caller passing an "unsigned long" value passing a register 
> value that would not be possible for an "int" argument, so causing 
> undefined behavior in the C code.  In particular, what does the powerpc64 
> ABI say about any required extension of incoming "int" arguments to C 
> functions?

I discussed this issue on linux-man bts and David pointed out we are already
using bit 31.
 
  https://bugzilla.kernel.org/show_bug.cgi?id=42705.

Moreover, this makes more drastic affect into interpreter language likes
ruby. Because of, such language have big integer than 32bit even though running
on 32bit system and their ioctl glue verify argument value range. so this change
will break such glue code.

A years ago, I and ruby folks discussed ioctl type issue.

http://bugs.ruby-lang.org/issues/5429 (sorry, it's japanese)


Summarize is here. 

== POSIX
int ioctl(int fildes, int request, ... /* arg */);
http://pubs.opengroup.org/onlinepubs/9699919799/functions/ioctl.html

== AIX
int ioctl (fd, request, .../*arg*/)
int  fd;
int  request;
int  .../*arg*/;
http://publib.boulder.ibm.com/infocenter/aix/v6r1/topic/com.ibm.aix.commtechref/doc/commtrf2/ioctl.htm

== Solaris
int ioctl(int fildes, int request, /* arg */ ...);
http://download.oracle.com/docs/cd/E19963-01/html/821-1463/ioctl-2.html

== HP-UX
int ioctl(int fildes, int request, ... /* arg */);
http://nixdoc.net/man-pages/HP-UX/man2/ioctl.2.html

== Tru64
int ioctl(
               int fildes,
               int request,
               ... /* arg */ );
http://nixdoc.net/man-pages/Tru64/man2/ioctl.2.html

== IRIX
int ioctl (int fildes, int request, ...);
http://nixdoc.net/man-pages/irix/man2/ioctl.2.html

== Linux
extern int ioctl (int __fd, unsigned long int __request, ...) __THROW;

 Nore: man pages say int ioctl(int d, int request, ...), but incorrect!
        https://www.kernel.org/doc/man-pages/online/pages/man2/ioctl.2.html

== NetBSD
int ioctl(int d, unsigned long request, ...);
http://netbsd.gw.com/cgi-bin/man-cgi?ioctl+2+NetBSD-current

== OpenBSD
int ioctl(int d, unsigned long request, ...);
http://www.openbsd.org/cgi-bin/man.cgi?query=ioctl&sektion=2&format=html

== Darwin
int ioctl(int fildes, unsigned long request, ...);
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/ioctl.2.html



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]