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=33168

This could be related to: patch 1309352.

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?

This was fixed in 2.5 with issue1231069.