[ python-Bugs-1619659 ] htonl, ntohl don't handle negative longs

[SourceForge.net]

Bugs item #1619659, was opened at 2006-12-20 18:42
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619659&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Adam Olsen (rhamphoryncus)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: htonl, ntohl don't handle negative longs

Initial Comment:
>>> htonl(-5)
-67108865
>>> htonl(-5L)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: can't convert negative value to unsigned long

It works fine in 2.1 and 2.2, but fails in 2.3, 2.4, 2.5.  htons, ntohs do not appear to have the bug, but I'm not 100% sure.

----------------------------------------------------------------------

>Comment By: Georg Brandl (gbrandl)
Date: 2007-01-17 21:26

Message:
Logged In: YES 
user_id=849994
Originator: NO

Guido, you applied the patch, can this bug be closed?

----------------------------------------------------------------------

Comment By: Mark Roberts (mark-roberts)
Date: 2007-01-14 07:36

Message:
Logged In: YES 
user_id=1591633
Originator: NO

It is here:

https://sourceforge.net/tracker/index.php?func=detail&aid=1635058&group_id=5470&atid=305470

I apologize for not getting to this sooner, but I've been working like a
frenzied devil at work.  Things have been really hectic with our customers
wanting year end reports.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-01-14 00:08

Message:
Logged In: YES 
user_id=6380
Originator: NO

mark-roberts, where's your patch?

----------------------------------------------------------------------

Comment By: Mark Roberts (mark-roberts)
Date: 2006-12-30 02:15

Message:
Logged In: YES 
user_id=1591633
Originator: NO

Hmmm, yes, I see a problem.  At the very least, I think we may be wanting
some consistency between the acceptance of ints and longs.  Also, I think
we should return an unsigned long instead of just a long (which can be
negative).

I've got a patch right now to make htonl, ntohl, htons, and ntohs never
return a negative number.  I'm rather waffling to the idea of whether we
should accept negative numbers at all in any of the functions.  The
behavior is undefined, and it is, afterall, better not to guess what a user
intended.

However, consistency should be a desirable goal, and we should accept make
the interface consistent for both ints and longs.

Mark

----------------------------------------------------------------------

Comment By: Adam Olsen (rhamphoryncus)
Date: 2006-12-28 21:37

Message:
Logged In: YES 
user_id=12364
Originator: YES

I forgot to mention it, but the only reason htonl should get passed a
negative number is that it (and possibly struct?) produce a negative
number.  Changing them to always produce positive numbers may be an
alternative solution.  Or we may want to do both, always producing positive
while also accepting negative.

----------------------------------------------------------------------

Comment By: Mark Roberts (mark-roberts)
Date: 2006-12-26 09:24

Message:
Logged In: YES 
user_id=1591633
Originator: NO

>From man page for htonl and friends:
       #include <arpa/inet.h>
       uint32_t htonl(uint32_t hostlong);
       uint16_t htons(uint16_t hostshort);
       uint32_t ntohl(uint32_t netlong);
       uint16_t ntohs(uint16_t netshort);

Python does call these underlying functions in Modules/socketmodule.c. 
The problem comes from that PyLong_AsUnsignedLong() called in
socket_htonl() specifically checks to see that the value cannot be less
than 0.  The error checking was rather exquisite, I might add.

- Mark

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619659&group_id=5470