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.
next 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: linkBe 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).