Issue 5895: socketmodule.c on HPUX ia64 without _XOPEN_SOURCE_EXTENDED compiles incorrectly (original) (raw)

Created on 2009-05-01 16:37 by ntai, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
hpux_socklen_t_int.diff ajaksu2,2009-05-08 18:56 Rough workaround: typedef socklen_t as int on HPUX ia64 review
Messages (4)
msg86889 - (view) Author: Naoyuki Tai (ntai) Date: 2009-05-01 16:37
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.
msg87459 - (view) Author: Daniel Diniz (ajaksu2) * (Python triager) Date: 2009-05-08 18:56
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.
msg139209 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2011-06-26 20:09
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.
msg139212 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-06-26 20:19
> 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
2012-04-12 03:56:24 adiroiban set nosy: + adiroiban
2011-06-26 20:19:30 loewis set messages: + title: socketmodule.c on HPUX ia64 without _XOPEN_SOURCE_EXTENDED compiles incorrectly -> socketmodule.c on HPUX ia64 without _XOPEN_SOURCE_EXTENDED compiles incorrectly
2011-06-26 20:09:22 terry.reedy set nosy: + loewis, terry.reedymessages: + versions: + Python 3.2, Python 3.3, - Python 2.6, Python 3.1
2009-05-08 18:56:24 ajaksu2 set files: + hpux_socklen_t_int.diffpriority: normalcomponents: + Buildversions: - Python 2.5, Python 3.0keywords: + patchnosy: + ajaksu2messages: + stage: test needed
2009-05-01 16:37:54 ntai create