The attached is a fix for the same problem that is
reported in 767150.  For 2.3.x and head cvs this
problem exists in the code path taken if configure does
not detect inet_aton.  I have not checked this against
2.2, which is the platform 767150 reports it against,
there may be header inclusion issues that make it not
work there but the essence is that the quantity worked
with has to be forced to be a 32-bit quanitity, not
declared unsigned long.

The patch is only one line, changing a unsigned long to in_addr_t. Could someone familiar with/with access to Linux on an IA64 machine take a look at this?

Thomas, I notice a lot of posts from you about 64-bit issues... ; )

This is a patch for issue 767150, which was closed in 2005.

I'm not sure in_addr_t is available everywhere. "unsigned int" should be
a good bet, since it is 32-bits in most platforms. Guarding the code
with a "#if (SIZEOF_INT == 4)" and erroring out otherwise will make the
patch ok (and, please add a test).

Sorry, reopening.

Test from issue 767150:
"""
socket.inet_aton() returns an 8 byte string when built 
on Linux/IA64. This should be 4 bytes on all 
architectures. Example:

>>> import socket
>>> socket.inet_aton('192.168.2.1')
'\xc0\xa8\x02\x01\x00\x00\x00\x00'
"""

The bug was confirmed by a third-party in 2006:
http://mail.python.org/pipermail/python-list/2006-August/400655.html

fixing now.

fixed in trunk r69519.

needs backporting to release26-maint and release30-maint.  leaving open 
until that happens.

Ping?
This has been merged to py3k with r69560 and is present in 3.1, what
about 2.6?

Fixed in release26-maint r76022.  This will appear in Python 2.6.5.

I'm leaving release30-maint alone as it is already in 3.1.

sorry for not making it into 2.6.3/2.6.4 despite the code being ready.  I 
should've set this as a release blocker.