mirror of
https://github.com/python/cpython.git
synced 2025-08-01 23:53:15 +00:00
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:
parent
48581c5f08
commit
a5cfcad0e3
3 changed files with 44 additions and 6 deletions
|
@ -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;
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue