First, I write python program on Linux. The function ioctl of fcntl module, take a integer parameter as ioctl command. in python 2.3.x, if this command value is more than 0x80000000, interpreter will popup some warnning message. but in python 2.4.x, it raise a exception directly. My solution is writing one cutoms module in C. but this is so ugly. There are some ioctl command value are more than 0x80000000, I think we should not reject "negative" ioctl command. enjoy.
Logged In: YES user_id=6656 I think this is fixed in CVS HEAD. Can you try that? As a workaround, you can probably pass ~int(~v&0xFFFFFFFF) to ioctl instead of v (which is very ugly, yes, but probably not as ugly as a C extension).
Logged In: YES user_id=6656 Uh, no, that patch is about fcntl, this report is about ioctl. ioctl has been fixed in CVS, afaik, so this report should probably be closed unless the OP shows up and tells us it isn't. Something similar should almost certainly be done to fcntl. That's what 1309352 is about. Maybe I should have fixed fcntl when I did ioctl, but I actually use ioctl and don't use fnctl myself...
Logged In: YES user_id=33168 Ah, I see. I was confused since both are in the fcntl module. I agree this bug isn't related to the patch. This got me looking into fcntl.ioctl() and I wonder if there's still not a problem. In the patch, I had to make arg a long which is consistent with fcntl() doc. ioctl() says the param is ..., so I don't know if it should be an int or a long. The current ioctl uses an int (lines 98 and 175). ISTM that arg should probably be unsigned (like the code variable) or a long here. (By unsigned I mean at least the format 'I' instead of 'i', if not the variable itself.) Any ideas?
