This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: ioctl has problems on 64 bit machines
Type: Stage:
Components: Library (Lib) Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: georg.brandl, lordsutch, stephennorris
Priority: normal Keywords:

Created on 2005-01-31 04:55 by stephennorris, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (3)
msg24109 - (view) Author: Stephen Norris (stephennorris) Date: 2005-01-31 04:55
fcntly.ioctl takes an int as the second argument. If
the value passed is a large 32 bit quantity (0x80046601
for example - EXT2_IOC_GETFLAGS) then I get:

Traceback (most recent call last):
  File "CommSecure-CVS/Operations/checkSpace.py", line
73, in ?
    main(sys.argv[1:])
  File "CommSecure-CVS/Operations/checkSpace.py", line
25, in main
    os.path.walk(file, doDirectory, total)
  File "/usr/lib64/python2.3/posixpath.py", line 282,
in walk
    func(arg, top, names)
  File "CommSecure-CVS/Operations/checkSpace.py", line
61, in doDirectory
    flags = fcntl.ioctl(fd, EXT3_IOC_GETFLAGS, "    ")
OverflowError: signed integer is greater than maximum

My _guess_ here is that the code is checking against 32
bit quantities rather than 64 bit when converting to
the C data type?

Platform is Linux, Fedora Core 3 on AMD Opteron.
msg24110 - (view) Author: Chris Lawrence (lordsutch) Date: 2005-07-21 01:11
Logged In: YES 
user_id=6757

The problem seems to be that Python integers are "long int,"
while the type expected by ioctl(2) is "unsigned long int"
(on AMD64, at least).

My hackish workaround is to coerce the ioctl number to a
signed quantity:

op = struct.unpack('i', struct.pack('I', op))[0]

Once it gets into the C code, the signed quantity is then
coerced back to unsigned long int by the ioctl call (after
an intermediate stop as (signed) int).

Probably, the correct course of action here is to figure out
what type ioctl(2) uses on a particular architecture and
adjust the PyArgs_ParseTuple() call and the type of "op"
accordingly.
msg24111 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2005-07-28 07:06
Logged In: YES 
user_id=1188172

Should be fixed wrt patch 1231069.
History
Date User Action Args
2022-04-11 14:56:09adminsetgithub: 41506
2005-01-31 04:55:19stephennorriscreate