Python can build without _XOPEN_SOURCE_EXTENDED on HPUX ia64 but the socket module is bust. This is because APIs like getsockname() do not use socklen_t*. Instead it is defined using int* for some of arguments. In socketmodule.c, it consistently use socklent_t which is the right thing for the rest of world. Because socklent_t is 64bit (same as size_t) and int is 32bit, it compiles with warnings of different types of pointer but it compiles anyway. The result is that, getsockname(), etc. take a look at the 32bit out of 64bit value thinking it is "zero" (big endian machine). APIs succeed without error but the result does not come back since the API calls think that the return value buffer size is 0. My Python build is 2.5. I think the same is true for all versions thereafter. I wish I could give you a diff but I don't know well enough the socketmodule.c what's the right thing to do. I cannot use _XOPEN_SOURCE_EXTENDED as I have other python bindings and modules built without _XOPEN_SOURCE_EXTENDED.
Naoyuki, Is the API a mix of size_t and int? Does the attached patch help? If you could confirm that building with _XOPEN_SOURCE_EXTENDED doesn't need a change, the #ifdef should check for that too.
Naoyuki, unless you can confirm that Daniel's patch works, we will have to close this as out-of-date. Martin: PEP 11 lists platforms no-longer supported, but does not list those that are. For writing/reviewing patches like this, it would be helpful if it did. Is __hpux __ia64 a supported platform, so that this would be a legal patch? With the OP apparently not interested, there seems to be no one to test such patches.
> Martin: PEP 11 lists platforms no-longer supported, but does not list > those that are. You mean, "doesn't list the platforms that are still supported"? That's on purpose: the point of PEP 11 is to warn current users about forthcoming changes, not to track support status for specific platforms. > For writing/reviewing patches like this, it would be > helpful if it did. Is __hpux __ia64 a supported platform, so that > this would be a legal patch? With the OP apparently not interested, > there seems to be no one to test such patches. Python never worked really well on HP-UX, but it worked in some form for a long time. Don't know whether that makes it a "supported platform". Accepting patches for HP-UX is fine with me. It would be better if some committer could confirm that the patch actually works, and also confirm that it doesn't break other releases of HP-UX.
History
Date
User
Action
Args
2022-04-11 14:56:48
admin
set
github: 50145
2016-09-28 09:43:34
christian.heimes
set
status: open -> closedresolution: out of datestage: test needed -> resolved
messages: + title: socketmodule.c on HPUX ia64 without _XOPEN_SOURCE_EXTENDED compiles incorrectly -> socketmodule.c on HPUX ia64 without _XOPEN_SOURCE_EXTENDED compiles incorrectly