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:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756021&group_id=5470
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(&quot;255.255.255.255&quot;) 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('255.255.255.255') raises
an exception while it should be a valid address. */
This patch (against Python CVS) fixes this problem by
special-casing &quot;255.255.255.255&quot; as input when
inet_addr returns -1 (usually an error). We just
strcmp() the input string with &quot;255.255.255.255&quot; 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 &quot;255.255.255.255&quot; 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
&quot;255.255.255.255&quot; 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
Message:
Logged In: YES
user_id=129426
Looks good but I have one suggestion:
isn't it better to test for "255.255.255.255" 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:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=756021&group_id=5470