ioctl has problems on 64 bit machines

[stephennorris]

BPO	1112949
Nosy	@birkenfeld

^{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:

assignee = None
closed_at = <Date 2005-07-28.07:06:52.000>
created_at = <Date 2005-01-31.04:55:19.000>
labels = ['library']
title = 'ioctl has problems on 64 bit machines'
updated_at = <Date 2005-07-28.07:06:52.000>
user = 'https://bugs.python.org/stephennorris'

bugs.python.org fields:

activity = <Date 2005-07-28.07:06:52.000>
actor = 'georg.brandl'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2005-01-31.04:55:19.000>
creator = 'stephennorris'
dependencies = []
files = []
hgrepos = []
issue_num = 1112949
keywords = []
message_count = 3.0
messages = ['24109', '24110', '24111']
nosy_count = 3.0
nosy_names = ['georg.brandl', 'lordsutch', 'stephennorris']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1112949'
versions = []

[stephennorris]

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.

[lordsutch]

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.

[birkenfeld]

Logged In: YES
user_id=1188172

Should be fixed wrt patch 1231069.