Repository navigation
fcntl_ioctl still not 100% sane with unsigned longs #60328
Description
Activity
As discussed in ID bpo-1471, the type for request is not 100% correct on some platforms (FreeBSD, NetBSD, and OpenBSD, for instance) and the custom platform that I'm using unfortunately uses non-32-bit int ioctls. An autoconf test needs to be added for these platforms and the request parameter needs to be handled properly (I'll take charge of doing that).
- addedextension-modulesC modules in the Modules dirC modules in the Modules dirtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
on Oct 4, 2012 Is it affected for 3.3 and 3.4 also?
Yes. Submitting a patch to fix this based on hg master shortly..
$ uname -a FreeBSD bayonetta.local 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r240836M: Sat Sep 22 12:30:11 PDT 2012 gcooper@bayonetta.local:/usr/obj/store/freebsd/stable/9/sys/BAYONETTA amd64 $ ./configure --prefix=/scratch/python-bin/3k/ ... $ make all; make install ... $ /scratch/python-bin/3k/bin/python3 Lib/test/test_ioctl.py test_ioctl (__main__.IoctlTests) ... ok test_ioctl_mutate (__main__.IoctlTests) ... ok test_ioctl_mutate_1024 (__main__.IoctlTests) ... ok test_ioctl_mutate_2048 (__main__.IoctlTests) ... ok test_ioctl_signed_unsigned_code_param (__main__.IoctlTests) ... ok
Ran 5 tests in 0.003s
OK
Sorry; previous patch is not applicable to this issue. This one is.
And I missed the int -> unsigned int part. Resubmitting one last time for tonight..
Grr... Let's try again.
... g'night.
This looks as a duplicate of bpo-521723 and bpo-1471. Do you have tests that demonstrate a failure with using ioctl on OpenBSD? May be there are problems on 64-bit big-endian platforms (or even on 64-bit little-endian if additional parameters are passed to ioctl).
Yes, it's a duplicate. That being said, documentation alone it should be unsigned long for Darwin (OS/X), FreeBSD, OpenBSD. Looking at the definition for ioctl(2), the below example would cause a failure.
I need to hunt around for a practical example as I don't have one offhand (it's something that was found a long time ago in a couple of python 2.6 at my current employer because they have ioctl's that go beyond the 32-bit boundary IIRC...)
fuji:~ ngie$ clang -Wall -c test_ioctl.c fuji:~ ngie$ clang -DBROKEN -Wall -c test_ioctl.c test_ioctl.c:9:9: warning: incompatible pointer types initializing 'ioctl_t' (aka 'int (*)(int, int, ...)') with an expression of type 'int (int, unsigned long, ...)' [-Wincompatible-pointer-types] ioctl_t _ioctl = ioctl; ^ ~~~~~ 1 warning generated. fuji:~ ngie$ cat test_ioctl.c #include <sys/ioctl.h> #ifdef BROKEN typedef int (*ioctl_t)(int, int, ...); #else typedef int (*ioctl_t)(int, unsigned long, ...); #endif
ioctl_t _ioctl = ioctl;
fuji:~ ngie$ uname -a
Darwin fuji.local 13.4.0 Darwin Kernel Version 13.4.0: Wed Dec 17 19:05:52 PST 2014; root:xnu-2422.115.10~1/RELEASE_X86_64 x86_64Another note: mixed endianness might have been a factor as previous versions of the product that were shipped used bi-arch x86 (32-bit userland on 64-bit kernel.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: