[issue1506] func alloca inside ctypes lib needs #include on solaris
Changes by Maarten Thibaut: -- components: Library (Lib) nosy: mthibaut severity: normal status: open title: func alloca inside ctypes lib needs #include on solaris type: compile error versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1506> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1506] func alloca inside ctypes lib needs #include on solaris
New submission from Maarten Thibaut: On Solaris, alloca() is a #define which is inside . Ctypes fails to compile because the #define is missing. Please fix by adding the following at the front of these 2 files: #if defined (__SVR4) && defined (__sun) # include #endif __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1506> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1506] func alloca inside ctypes lib needs #include on solaris
Changes by Maarten Thibaut: -- components: +Extension Modules -Library (Lib) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1506> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1506] func alloca inside ctypes lib needs #include on solaris
Maarten Thibaut added the comment: forgot to mention the files: Modules/_ctypes/callproc.c Modules/_ctypes/libffi/src/sparc/ffi.c __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1506> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1711] socket functions that should return unsigned int return signed int
New submission from Maarten Thibaut:
Socket library functions such as ntohs() return uint16_t, but inside
Python these return values show up as negative numbers. One possible fix
is to convert these return values using pack:
struct.unpack('H', struct.pack('h', ntohs(number)))[0] & 0x
--
components: Library (Lib)
messages: 59047
nosy: mthibaut
severity: normal
status: open
title: socket functions that should return unsigned int return signed int
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1711>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1711] socket functions that should return unsigned int return signed int
Maarten Thibaut added the comment: Numbers returned from ntohs() turn up as negative. But ntohs() is typed as uint16_t, so they shouldn't be. This is on solaris. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1711> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1711] socket functions that should return unsigned int return signed int
Maarten Thibaut added the comment: Try this on Linux and Solaris: --- from socket import ntohs, htons print ntohs(htons(55000)) --- On Linux: 55000 On Solaris: -10536 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1711> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1711] socket functions that should return unsigned int return signed int
Maarten Thibaut added the comment: Guido, the problem is that my python foo is severely lacking - but I'll have a stab at it. Python believes that the number coming back from the C library is negative. We can fool it by packing the "signed short" into a system-native format, and then unpacking it explicitly into an unsigned short. So I propose to do precisely that on big endian systems using sys.byteorder: wrap these functions with a converter. Would that be acceptible? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1711> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
