According to the checkin comment for Modules/socketmodule.c v. 1.91:
Port inet_ntoa and inet_aton to Windows:
- fix unescaped newline in string literal - removed unused err variable - Windows doesn't have inet_aton; use inet_addr instead
However, in the man page for inet_addr it states:
This is an obsolete interface to inet_aton, described immediately above; it is obsolete because -1 is a valid address (255.255.255.255), and inet_aton provides a cleaner way to indicate error return.
The reason I bring it up is that a request came in today to python-help about python-2.2 on an SX supercomputer, which suggests that the code for handling INADDR_NONE (and thus inet_addr()) is broken:
I have compiled python-2.2 on an SX supercomputer which does not have inet_pton(). The emulated one in Modules/socketmodule.c is being used instead. The test for packed_addr against INADDR_NONE fails because:
1) INADDR_NONE is 0xffffffff in SX #include file, 2) long on SX is 8-bytes, 3) inet_addr() returns -1 (0xffffffffffffffff) which is -1, but _not_ INADDR_NONE.
Has this problem come up anywhere else with sizeof(long) == 8 and inet_addr() schizophrenia?
I realize that this may be an OS implementation issue (should inet_addr() return -1 or INADDR_NONE) but what should/can be done (if anything) to the Python package in order to address this?
It seems to me the simplest thing to do is to force a "proper" definition of INADDR_NONE with something like
#ifdef INADDR_NONE #undef INADDR_NONE #endif #define INADDR_NONE ((in_addr_t)-1)
if it's not defined and in_addr_t is available. The more correct thing would seem to be to dump inet_addr in favor of inet_aton unless the latter is unavailable.
On the other hand, perhaps just the SX include files are busted and all that has to happen is to override INADDR_NONE for that platform:
#if defined(INADDR_NONE) && INADDR_NONE != ((in_addr_t)-1) #undef INADDR_NONE #define INADDR_NONE ((in_addr_t)-1) #endif
Unfortunately, my mastery of the C preprocessor, casts, and configure is insufficient to determine without some experimentation on a platform I have no acces to if either of these is a workable approach or if there is a better approach that will work on the SX.
Skip Montanaro email@example.com writes:
I'd agree that inet_aton should be use if available; autoconf is capable of finding that out. I do not think that the platform INADDR_NONE should be changed if available. On this specific platform, there seems to be a bug: INADDR_NONE is 0xffffffff, yet inet_addr returns -1. According to my Linux manpage, inet_addr ought to return INADDR_NONE on failure, so that should be defined as (or the return value of inet_addr should be different).
I guess most people share the problem of having no access to an SX installation, so if anything is done about this, the original poster would have to come up with a patch.