[Patches] [ python-Patches-756021 ] Allow socket.inet_aton("" ) on Windows

SourceForge.net noreply at sourceforge.net
Sun Jan 16 16:34:03 CET 2005

Patches item #756021, was opened at 2003-06-17 18:30
Message generated for change (Comment added) made by irmen
You can respond by visiting: 

Category: Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Gertzfield (che_fox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow socket.inet_aton("") on Windows

Initial Comment:
Currently there's an XXX comment in socketmodule.c for
the Windows implementation (actually, for any platform
that doesn't have inet_aton) of socket.inet_aton:

/* XXX Problem here: inet_aton('') raises
   an exception while it should be a valid address. */

This patch (against Python CVS) fixes this problem by
special-casing "" as input when
inet_addr returns -1 (usually an error).  We just
strcmp() the input string with "" if
inet_addr returned -1; if it matches, we allow
PyString_FromStringAndSize() to do its thing on -1.

Also, I noticed that the unit tests for
module.inet_aton and friends were skipped if the
platform didn't have inet_pton; this is an obvious
error, and so I've split out the tests for inet_pton
and inet_ntop's IPv4 functionality from inet_aton and
inet_ntoa, as well as adding an explicit test for the
now-handled "" case.

Finally, I haven't gotten CVS python to build on
Windows under Visual Studio.NET (I get 'invalid project
errors' when it tries to convert the VS6 project files
-- and I don't have VS6) although I've tested this
patch and the new tests on Debian Linux.  

This patch really should be applied to the 2.2
maintenance branch as well as 2.3, since
"" is a legal IP address and is not
documented to raise an exception in the Python docs
(even though it does currently on Windows).


Comment By: Irmen de Jong (irmen)
Date: 2005-01-16 16:34

Logged In: YES 

Looks good but I have one suggestion:
isn't it better to test for "" before calling
inet_addr and then return '\xff\xff\xff\xff' directly,
rather than relying on INADDR_NONE being 0xffffffff ?


You can respond by visiting: 

More information about the Patches mailing list