Gregory P. Smith <[EMAIL PROTECTED]> added the comment: I am unable to reproduce this problem at all on Mac OS X 10.4 or 10.5 with 32-bit or 64-bit python trunk builds.
I have however checked in a fix that'll prevent negative code values passed in from being sign extended to 64-bits when converted to an unsigned long on platforms that use those. A unittest for fcntl.ioctl behavior when passed both positive and negative values is included. trunk r61652 while the Linux man page describe's ioctl's code parameter as an int, the sys/ioctl.h file on linux has it as an unsigned long int in the function prototype. So its quite possible it is actually an unsigned long on all platforms and we should change unsigned int code to unsigned long code and the 'I' to a 'k'. However if that is done we -might- have a sign extension problem again if anyone is passing a negative value in and expecting it to act like a 32-bit value. If the OS kernels only look at the lower 32-bits of the ioctl code during the syscall it'd work, but if it tested the 64bit value -123 64bit != -123 32bit. The better answer to that would be to just reject all negative values and fix any defined ioctl code constants to be positive on all platforms. fbvortex. Can you apply the change from svn to your python and test that it works properly on your 64-bit OpenBSD system? Thanks. paste a note here once you have with the results. ---------- resolution: -> fixed status: open -> pending __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1471> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
