[issue1471] ioctl doesn't work properly on 64-bit OpenBSD
Nicholas Marriott added the comment:
I can also reproduce this on OpenBSD/amd64 and was one of the people who
discussed it with the submitter before he created this report.
> So what's the definition of struct winsize on these systems?
The definition of struct winsize on both 32-bit and 64-bit OpenBSD
platforms is:
struct winsize {
unsigned short ws_row; /* rows, in characters */
unsigned short ws_col; /* columns, in characters */
unsigned short ws_xpixel; /* horizontal size, pixels */
unsigned short ws_ypixel; /* vertical size, pixels */
};
We have verified that (sizeof (struct winsize)) is 8 on all three
platforms (32-bit i386, and 64-bit amd64 and sparc64).
> Also, why do you think this is a bug in Python? AFAICT, the specific
> ioctl call does not occur in Python, but in your own code.
This Python code fails:
fcntl.ioctl(fd, termios.TIOCSWINSZ, struct.pack("",80,25,0,0))
(Error: IOError: [Errno 25] Inappropriate ioctl for device) This code
also fails with the same error message (I would expect EINVAL instead):
fcntl.ioctl(0, termios.TIOCSWINSZ, "")
Corresponding test C code to call the ioctl (as listed in a previous
message) works without problems on all three platforms. I don't know how
Python fcntl.ioctl works and perhaps the problem is not Python, but I am
having to try fairly hard to think what else could be involved.
The constant appears to be the correct ioctl number. (Python code:
python2.5 -c 'import termios; print "%d" % (termios.TIOCSWINSZ)'
matches C code:
#include
int main(void) { printf("%ld\n", TIOCSWINSZ); }
on all three platforms.)
I am told it works on Linux. However, Linux declares ioctl as:
int ioctl(int d, int request, ...);
So 'request' is 32-bits, but on OpenBSD ioctl is declared as:
int ioctl(int d, unsigned long request, ...);
So on amd64 and sparc64, 'request' is 64-bits. Could this be a factor?
-- Nicholas.
--
nosy: +nicm
__
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
[issue1471] ioctl doesn't work properly on 64-bit OpenBSD
Nicholas Marriott added the comment:
Okay, looks like my guess was correct. The diff at the end of this mail
makes it work on OpenBSD/amd64 and it continues to work on i386, but it
will probably break Linux (due to the problem it was working around
mentioned in the comment at the beginning). I don't know enough about
the Python build system to suggest a correct fix. (SUSv3 seems to
suggest ioctl's request should be int, so perhaps OpenBSD is ultimately
at fault.)
fcntl_ioctl in fcntlmodule.c seems to have some other potential
problems on 64-bit archs too, as it seems to coerce the ioctl argument
(potentially a pointer) into an int.
-- Nicholas.
--- fcntlmodule.c.orig Tue Nov 20 09:39:12 2007
+++ fcntlmodule.c Tue Nov 20 09:59:50 2007
@@ -101,7 +101,7 @@
the signed int 'code' variable, because Python turns
0x800
into a large positive number (PyLong, or PyInt on 64-bit
platforms,) whereas C expects it to be a negative int */
- int code;
+ unsigned long code;
int arg;
int ret;
char *str;
@@ -109,7 +109,7 @@
int mutate_arg = 1;
char buf[IOCTL_BUFSZ+1]; /* argument plus NUL byte */
- if (PyArg_ParseTuple(args, "O&Iw#|i:ioctl",
+ if (PyArg_ParseTuple(args, "O&Lw#|i:ioctl",
conv_descriptor, &fd, &code,
&str, &len, &mutate_arg)) {
char *arg;
@@ -160,7 +160,7 @@
}
PyErr_Clear();
- if (PyArg_ParseTuple(args, "O&Is#:ioctl",
+ if (PyArg_ParseTuple(args, "O&Ls#:ioctl",
conv_descriptor, &fd, &code, &str, &len))
{
if (len > IOCTL_BUFSZ) {
PyErr_SetString(PyExc_ValueError,
@@ -182,7 +182,7 @@
PyErr_Clear();
arg = 0;
if (!PyArg_ParseTuple(args,
-"O&I|i;ioctl requires a file or file descriptor,"
+"O&L|i;ioctl requires a file or file descriptor,"
" an integer and optionally an integer or buffer argument",
conv_descriptor, &fd, &code, &arg)) {
return NULL;
__
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
[issue12181] SIGBUS error on OpenBSD (sparc64)
Nicholas Marriott added the comment: Hi This is not an OpenBSD bug. kqueue is not standardized. There is no reason for the ident member to be uintptr_t over u_int - either is valid, and so far I don't see any reason for us to try and change it. -- nosy: +nicm ___ Python tracker <http://bugs.python.org/issue12181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12181] SIGBUS error on OpenBSD (sparc64)
Nicholas Marriott added the comment: To follow up a little - I'm afraid that you should not depend on the internal layout of structures like this. We clearly document the kevent structure in kevent(2), and of course beyond that it is of course dependent on C padding rules. It isn't a bug that we have different layout from FreeBSD. If you can make a case for us to change the layout then maybe... -- ___ Python tracker <http://bugs.python.org/issue12181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12181] SIGBUS error on OpenBSD (sparc64)
Nicholas Marriott added the comment:
Hi
The second one is correct - OpenBSD -current has this in event.h:
struct kevent {
u_int ident; /* identifier for this event */
short filter; /* filter for event */
u_short flags;
u_int fflags;
int data;
void*udata; /* opaque user data identifier */
};
It's been like that since r1.1 so probably the 3.8 man page was wrong.
I don't know that backwards compatibility would be the main concern here, more
what is the justification for changing. It does make sense to have ident wide
enough to store a pointer so it would be better as a long, but making filter
and flags into uint32_t seems unnecessary and I think udata is fine as a void*.
--
___
Python tracker
<http://bugs.python.org/issue12181>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12181] SIGBUS error on OpenBSD (sparc64)
Nicholas Marriott added the comment: Not that I'm unsympathetic but this is really only a concern if you depend on the internal structure layout and I think if you do that, you need to take account of differences between platforms. We don't guarantee we aren't going to change the struct between versions and I doubt FreeBSD or NetBSD or OS X would make that guarantee either :-). I'll see if we can change it but no promises and even if we do it'll be for later versions of OpenBSD anyway... -- ___ Python tracker <http://bugs.python.org/issue12181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12181] SIGBUS error on OpenBSD (sparc64)
Nicholas Marriott added the comment: Well "they do it that way" is not a justification that necessarily works for OpenBSD :-). I'll see if I can come up with a diff to fix this in Python. Not this weekend though, maybe next week. Unless Remi do you want to have a go? -- ___ Python tracker <http://bugs.python.org/issue12181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1471] ioctl request argument broken on 64-bit OpenBSD or OS X
Nicholas Marriott <[EMAIL PROTECTED]> added the comment: I was going to test this on sparc64 (I no longer have access to amd64) but I've been busy/on holiday, I'll try to do it this week. ___ Python 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
[issue1471] ioctl doesn't work properly on 64-bit OpenBSD
Nicholas Marriott <[EMAIL PROTECTED]> added the comment: It's not the return value, it's the request argument (second argument). I thought SUSv3 had it as an int, but looking again its ioctl seems to be a) optional and b) all about STREAMS, so I don't think it applies: http://www.opengroup.org/onlinepubs/009695399/functions/ioctl.html -- Nicholas __ 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
