This comes up as an error on platforms with a 32 bit
in_addr_t type, because 0xFFFFFFFF -> -1 -> INADDR_ANY
-> error condition.  socketmodule's inet_aton() should
probably be changed to use inet_aton if available (I'm
not sure how to make the appropriate platform checks,
or I'd submit a patch).  It isn't clear to me the best
way to work around this on platforms lacking
inet_aton(), short of re-implementing its functionality.

Logged In: YES 
user_id=539787

I'm in the process of trying to make a patch, since I found this 
relating to a mistaken 8-byte result in 64-bit machines.  
When I come up with an answer, I will post a link to the patch 
here.

Logged In: YES 
user_id=6380

Fixed in Python 2.3 CVS by using inet_aton().

Does this need to be backported to 2.2.3?

Logged In: YES 
user_id=539787

I believe all users having used the old inet_aton have used 
workarounds if 0xffffffff could be used as an argument (I know I 
have).  It sure would be nice, though (and make 2.2.3 
the "industrial strength" version :)

Logged In: YES 
user_id=6380

The fix needed configuration work because Windows doesn't
have inet_aton(). :-)

I'm calling for a volunteer to backport this to 2.2.3.

Logged In: YES 
user_id=539787

If none other volunteers, I'll give it a shot during the weekend (I 
don't have VC++ but a friend has, and I need to download the 
current 2.2.3 tree).