Prevent ioctl op codes from being sign extended from int to unsigned long

when used on platforms that actually define ioctl as taking an unsigned long.
(the BSDs and OS X / Darwin)

Adds a unittest for fcntl.ioctl that tests what happens with both positive and
negative numbers.

This was done because of issue1471 but I'm not able to reproduce -that- problem
in the first place on Linux 32bit or 64bit or OS X 10.4 & 10.5 32bit or 64 bit.
This commit is contained in:
Gregory P. Smith 2008-03-19 23:03:25 +00:00
parent 48581c5f08
commit a5cfcad0e3
3 changed files with 44 additions and 6 deletions

View file

@ -97,11 +97,20 @@ fcntl_ioctl(PyObject *self, PyObject *args)
{
#define IOCTL_BUFSZ 1024
int fd;
/* In PyArg_ParseTuple below, use the unsigned int 'I' format for
the signed int 'code' variable, because Python turns 0x8000000
into a large positive number (PyLong, or PyInt on 64-bit
platforms,) whereas C expects it to be a negative int */
int code;
/* In PyArg_ParseTuple below, we use the unsigned non-checked 'I'
format for the 'code' parameter because Python turns 0x8000000
into either a large positive number (PyLong or PyInt on 64-bit
platforms) or a negative number on others (32-bit PyInt)
whereas the system expects it to be a 32bit bit field value
regardless of it being passed as an int or unsigned long on
various platforms. See the termios.TIOCSWINSZ constant across
platforms for an example of thise.
If any of the 64bit platforms ever decide to use more than 32bits
in their unsigned long ioctl codes this will break and need
special casing based on the platform being built on.
*/
unsigned int code;
int arg;
int ret;
char *str;