[issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2).

Dong-hee Na added the comment: Can I take a look at this issue? Is there anything should I care about except update clinic? Thanks! -- nosy: +corona10 ___ Python tracker ___

[issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2).

Change by Manuel Cerón : -- nosy: +ceronman ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2).

Martin Panter added the comment: Maybe Issue 16124 is related; it mentions 64-bit values, but it sounds like an obscure use case. -- ___ Python tracker

[issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2).

Serhiy Storchaka added the comment: The question is: are ioctl codes outside of the unsigned int range used on BSD family or Mac OS X? -- ___ Python tracker

[issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2).

koobs added the comment: @Serhiy If anyone can provide me some test code (I dont know how to test it) I'm happy to test it on 'unpatched' 2.7 and 3.5 ports -- ___ Python tracker

[issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2).

koobs added the comment: Thanks for the insight Serhiy. A few questions .. Is clinic code updated based on *.c declarations at build time? If not when/how is the best place/method to run this for our ports/package builds? Does your suggestion to switch unsigned_int to unsigned_long imply that

[issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2).

koobs added the comment: @Serhiy If by "type of code at the time of commit" you mean upstream python code, msg250163 contains a link to what bits we replace in fcntlmodule.c and that "I -> k" has always been the same. -- ___ Python tracker

[issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2).

Serhiy Storchaka added the comment: Originally the type of the code variable in fcntl_ioctl() was int. In cbad1f5cabb1 it was changed to unsigned int. I guess that the log message that you cited was written before this. -- ___ Python tracker

[issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2).

New submission from koobs: In my current attempt to create a FreeBSD port for python35, I've come across a patch rejection for the fcntlmodule.c for a local port patch we've been carrying since Python 2.6:

[issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2).

Serhiy Storchaka added the comment: You need just replace unsigned_int with unsigned_long in Clinic declaration for fcntl.ioctl in Modules/fcntlmodule.c and regenerate Clinic code (make clinic). -- nosy: +larry, serhiy.storchaka ___ Python tracker

[issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2).

Serhiy Storchaka added the comment: No, the clinic code is not updated at build time. Your should either update clinic code just after patching Modules/fcntlmodule.c (Python 3 is needed), or update clinic code at patch creation time and include changes of generated clinic files in the patch.

[issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2).

Martin Panter added the comment: If necessary, perhaps we could unconditionally change the Python-level argument to unsigned_long, and then add a conditional bit in the C code to convert it to int if appropriate. But I wonder if most of the problem is fixed by Issue 1471 (linked from the