On Solaris, socket.ntohs() can return a negative number
when the argument has bit 15 set. This is not according
to spec or intention or expectation. The bug is because
on Solaris, ntohs() is defined as a macro that returns
its argument unchanged, roughly:

  #define ntohs(x) (x)

The socket extension casts the argument to (short); it
should use (unsigned short) or something similar.

Here's a program showing the problem (run this on
Solaris, or on another big-endian machine where ntohs()
is defined away):

import socket
print socket.ntohs(-1)

This should print 65535 but prints -1.

(Credit to Andrew Davis for finding this!)

Logged In: YES 
user_id=6380

Of course, htons has the same problem.  The 'l' versions are
unaffected.

Logged In: YES 
user_id=1019660

Hi,

Just checked this on my solaris 9 box:

Python 2.3.3 (#1, Apr 12 2004, 21:32:46) 
[GCC 2.95.3 20010315 (release)] on sunos5
Type "help", "copyright", "credits" or "license" for more
information.
>>> 
>>> 
>>> import socket
>>> print socket.ntohs(-1)
65535


It looks fine. what system are you running on when doing
this test. 
Most likely can be a bug and needs a patch. You can always
check the release number as:

cat /etc/release

Cheers
Stefan Parvu

Logged In: YES 
user_id=1019660

My mistake. The problem is in there but only Solaris sparc!
On x86 this is not a problem.

stefan@/export/home/stefan>/opt/sfw/bin/python
Python 2.2.3 (#1, Sep  6 2003, 09:33:14) 
[GCC 2.95.3 20010315 (release)] on sunos5
Type "help", "copyright", "credits" or "license" for more
information.
>>> 
>>> 
>>> import socket
>>> print socket.ntohs(-1)
-1


stefan

Logged In: YES 
user_id=6380

Hm...  I (now) get the problem with Python 2.2 but not with 
2.3.3.  This is on Sparc Solaris 9. (I like uname -sr better to 
know the release, as long as you know that SunOS 5.8 is 
Solaris 8 and SunOS 5.9 is Solaris 9. Sigh, marketing. :-)

The weird thing is that I don't see any differences between 
the 2.2 and 2.3 version of socket_ntohs()...

But the 2.2 was taken from /opt/swf, so I presume it was 
built by Sun's open source folks, while I built the 2.3.3 
version myself.  Will investigate further...

Logged In: YES 
user_id=1019660

Hi,

I did some more tests. Im sorry but I don't have so many
machines around so Im limited to x86 and 1 sparc box.

Just checked again for Solaris x86. This problem looks like
sparc specific.


I have checked:

Solaris 9 x86 python 2.3.3 
Solaris 10 x86 python 2.3.2
Solaris 9 x86 python 2.2.3

Result: No problems found
I wanted to see many variants of python :)

I checked as well sparc arch:

Solaris 9 sparc python 2.2.3
Results: failed

It looks like the problem is around sparc arch. 
I have asked Sun as well about this, I will come back with
more details when I know something. 

You can not simulate this under 2.3.3 sparc ... that is strange.
Are you sure nobody patched the box meanwhile ... !?

Yeah, the thing I asked about /etc/release is that sometimes
if a bug is present in Solaris 9 Update 2 it will be fixed
in Update 3.
So it is better to see what update are you in first. 

The life cycle:

First Customer Ship - Solaris 9 FCS
<After 4 months>
Solaris 9 U1
<After 4 months>
Solaris 9 U2 
...

Update are not only patches, bug fixes, but some new things
introduced with that update release. 

regards,
stefan

Logged In: YES 
user_id=1019660

Hi,

More details. Indeed there is a defect on SPARC 
Bugid: 4186559 kernel ntohs and htons functions can return
out-of-range values on SPARC

and it is under work.
As an workaround please : cast the return value of ntohs and
htons to (unsigned short)

cheers,
stefan

The ntohs bug was fixed in Python 2.6.