This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: htonl, ntohl don't handle negative longs
Type: Stage:
Components: None Versions:
process
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: gvanrossum Nosy List: Rhamphoryncus, georg.brandl, gvanrossum, mark-roberts
Priority: normal Keywords:

Created on 2006-12-20 18:42 by Rhamphoryncus, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (7)
msg30840 - (view) Author: Adam Olsen (Rhamphoryncus) Date: 2006-12-20 18:42
>>> 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.
msg30841 - (view) Author: Mark Roberts (mark-roberts) Date: 2006-12-26 09:24
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
msg30842 - (view) Author: Adam Olsen (Rhamphoryncus) Date: 2006-12-28 21:37
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.
msg30843 - (view) Author: Mark Roberts (mark-roberts) Date: 2006-12-30 02:15
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
msg30844 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-01-14 00:08
mark-roberts, where's your patch?
msg30845 - (view) Author: Mark Roberts (mark-roberts) Date: 2007-01-14 07:36
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.
msg30846 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2007-01-17 21:26
Guido, you applied the patch, can this bug be closed?
History
Date User Action Args
2022-04-11 14:56:21adminsetgithub: 44367
2006-12-20 18:42:37Rhamphoryncuscreate