socket functions that should return unsigned int return signed int

[mthibaut]

BPO	1711
Nosy	@gvanrossum, @giampaolo, @tiran

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2008-07-20.11:16:54.004>
created_at = <Date 2007-12-30.21:30:45.612>
labels = ['type-bug', 'library']
title = 'socket functions that should return unsigned int return signed int'
updated_at = <Date 2008-07-20.11:16:54.003>
user = 'https://bugs.python.org/mthibaut'

bugs.python.org fields:

activity = <Date 2008-07-20.11:16:54.003>
actor = 'georg.brandl'
assignee = 'none'
closed = True
closed_date = <Date 2008-07-20.11:16:54.004>
closer = 'georg.brandl'
components = ['Library (Lib)']
creation = <Date 2007-12-30.21:30:45.612>
creator = 'mthibaut'
dependencies = []
files = []
hgrepos = []
issue_num = 1711
keywords = []
message_count = 10.0
messages = ['59047', '59049', '59050', '59051', '59052', '59074', '59075', '59076', '63845', '63848']
nosy_count = 5.0
nosy_names = ['gvanrossum', 'jafo', 'giampaolo.rodola', 'christian.heimes', 'mthibaut']
pr_nums = []
priority = 'low'
resolution = None
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue1711'
versions = []

[mthibaut]

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] & 0xffff

[tiran]

Which number shows up as a negative number on your system?

[mthibaut]

Numbers returned from ntohs() turn up as negative. But ntohs() is typed as
uint16_t, so they shouldn't be. This is on solaris.

[tiran]

Please provide an example number

[mthibaut]

Try this on Linux and Solaris:
-----------------------

from socket import ntohs, htons

print ntohs(htons(55000))
-----------------------

On Linux:
55000

On Solaris:
-10536

[gvanrossum]

This should be fixed. Maarten, can you create a patch that works for
you? (Since few of us have access to the platform where it breaks.)

[mthibaut]

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?

[gvanrossum]

Maarten, can you build Python 2.6 from svn? (See
http://www.python.org/dev/faq/#subversion-svn for help.)

It looks like this has been fixed there, per r53434. Perhaps the same
changes can be backported.

[jafo]

Maarten: Do you have time to try doing a test build as suggested by
Guido, to report if this issue is resolved?

[gvanrossum]

This is likely fixed; setting the status to pending and priority to low.
I believe this will eventually close it.