public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "torvalds@linux-foundation.org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sources.redhat.com
Subject: [Bug libc/14362] New: Incorrect ioctl declaration
Date: Thu, 12 Jul 2012 19:57:00 -0000	[thread overview]
Message-ID: <bug-14362-131@http.sourceware.org/bugzilla/> (raw)

http://sourceware.org/bugzilla/show_bug.cgi?id=14362

             Bug #: 14362
           Summary: Incorrect ioctl declaration
           Product: glibc
           Version: 2.15
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: unassigned@sourceware.org
        ReportedBy: torvalds@linux-foundation.org
                CC: drepper.fsp@gmail.com
    Classification: Unclassified


Both SuS and the man-pages agree: the correct declaration for ioctl() is

   extern int ioctl(int fd, int request, ...);

but glibc headers incorrectly have "unsigned long" for the request. 

This means that this simple C program results in an incorrect type conflict
error:

   #include <sys/ioctl.h>
   extern int ioctl(int fd, int request, ...);

even though the declaration clearly matches documentation.

Perhaps more importantly, it's misleading for anybody who actually reads the
header files. That's rare, but still.. We had this discussion on the subsurface
mailing list, because OS X has the same buggy declaration, and what is worse,
the OS X kernel is apparently buggy too, because doing

   int action = (level ? TIOCSBRK : TIOCCBRK);
   ...
   ioctl(fd, action, ...);

will sign-extend the 'int' into 'unsigned long', and the OS X FreeBSD-based
kernel apparently actually looks at all 64 bits of an 'unsigned long' when it
does things, leading to actual bugs (ie ioctl returning ENOTTY because the
sign-extended 64-bit value is not recognized).

So having "unsigned long" in there can result in actual bugs. You don't see
this on Linux, because 64-bit Linux will correctly truncate the request value
to 32 bits (and then internally uses 'unsigned' to make sure no sign extension
happens, but that's a separate issue).

So please fix the ioctl() declaration. "unsigned long" is misleading and
actively incorrect and can cause bugs on non-Linux operating systems.

In case anybody uses glibc on OS X, I would suggest doing

   int ioctl(int fd, int __request, ...)
   {
       unsigned long request = (unsigned int) __request;
       ...

to avoid the OS X bug.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


             reply	other threads:[~2012-07-12 19:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-12 19:57 torvalds@linux-foundation.org [this message]
2012-07-24  3:02 ` [Bug libc/14362] " carlos_odonell at mentor dot com
2012-07-24  3:07 ` carlos_odonell at mentor dot com
2012-07-24  3:59 ` carlos_odonell at mentor dot com
2012-07-24 15:27 ` kosaki.motohiro at jp dot fujitsu.com
2012-07-24 17:41 ` torvalds@linux-foundation.org
2012-12-04  0:00 ` carlos at systemhalted dot org
2013-01-15 11:33 ` schwab@linux-m68k.org
2013-01-15 17:04 ` torvalds@linux-foundation.org
2013-04-16  9:13 ` mmaruska at gmail dot com
2013-05-15 10:09 ` ondra at iuuk dot mff.cuni.cz
2013-05-15 14:28 ` carlos at redhat dot com
2014-02-16 19:30 ` jackie.rosen at hushmail dot com
2014-05-28 19:46 ` schwab at sourceware dot org
2014-06-17 18:59 ` fweimer at redhat dot com
2015-01-03  1:45 ` emaste at freebsd dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-14362-131@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).