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 "255.255.255.255" as input when inet_addr returns -1 (usually an error). We just strcmp() the input string with "255.255.255.255" 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 "255.255.255.255" 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 "255.255.255.255" is a legal IP address and is not documented to raise an exception in the Python docs (even though it does currently on Windows).
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 ?
