inet_addr usage in Modules/socketmodule.c?

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. Your thoughts? Skip

Skip Montanaro <skip@pobox.com> writes:
Your thoughts?
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. Regards, Martin
participants (2)
-
martin@v.loewis.de
-
Skip Montanaro