From: SourceForge.net <no...@so...> - 2012-04-14 17:31:17
|
Bugs item #3429388, was opened at 2011-10-27 10:54 Message generated for change (Comment added) made by wsfulton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=3429388&group_id=1645 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: python Group: None Status: Pending Resolution: Fixed Priority: 5 Private: No Submitted By: Hongbin Wei (weihongbin) Assigned to: Nobody/Anonymous (nobody) Summary: not handling 0xffffffff correctly as UINT32 input to C func Initial Comment: I have a C function “void Uint32_Test(UINT32 num)”. when I pass in a 0xffffffff as the argument from Python to the wrapper function, I get “overflowerror : in method ‘Uint32_Test’, argument 1 of type ‘UINT32’”. Looking into the wrappers, I found that the error is generated at the lines of following method marked by "<==". Obviously 0xffffffff is being treated as a singed value although it's expected to be an unsigned. SWIGINTERN int SWIG_AsVal_unsigned_SS_long (PyObject *obj, unsigned long *val) { if (PyInt_Check(obj)) { long v = PyInt_AsLong(obj); <== if (v >= 0) { <== if (val) *val = v; return SWIG_OK; } else { return SWIG_OverflowError; } } else if (PyLong_Check(obj)) { unsigned long v = PyLong_AsUnsignedLong(obj); if (!PyErr_Occurred()) { if (val) *val = v; return SWIG_OK; } else { PyErr_Clear(); } } #ifdef SWIG_PYTHON_CAST_MODE { int dispatch = 0; unsigned long v = PyLong_AsUnsignedLong(obj); if (!PyErr_Occurred()) { if (val) *val = v; return SWIG_AddCast(SWIG_OK); } else { PyErr_Clear(); } if (!dispatch) { double d; int res = SWIG_AddCast(SWIG_AsVal_double (obj,&d)); if (SWIG_IsOK(res) && SWIG_CanCastAsInteger(&d, 0, ULONG_MAX)) { if (val) *val = (unsigned long)(d); return res; } } } #endif return SWIG_TypeError; } ---------------------------------------------------------------------- >Comment By: William Fulton (wsfulton) Date: 2012-04-14 10:31 Message: This patch should not have gone in as it introduces failures in the python test-suite. Reverted (in rev 12983) until patch is fixed. ---------------------------------------------------------------------- Comment By: szager (szager) Date: 2011-11-04 20:36 Message: Fix committed as revision 12835. This will appear in the next SWIG release (2.0.5). ---------------------------------------------------------------------- Comment By: Hongbin Wei (weihongbin) Date: 2011-11-04 17:01 Message: Thanks, Stefan. Your latest patch works. ---------------------------------------------------------------------- Comment By: szager (szager) Date: 2011-11-01 11:52 Message: OK, I have updated the patch. Note that the new patch has diffs for two files, not one. Please try applying the patches to the SWIG source files, and *not* to your generated wrappers. A fix which can't be applied to source files is useless. Although it is confusing to see a change only in SWIG_AsVal_dec, that is in fact the correct place to fix this. Thanks, Stefan ---------------------------------------------------------------------- Comment By: Hongbin Wei (weihongbin) Date: 2011-10-31 16:12 Message: I looked at the patch. 1) On my system, it's SWIGINTERN int SWIG_AsVal_unsigned_SS_long (PyObject *obj, unsigned long *val) that got generated, called and triggered the failure, not SWIG_AsVal_dec(unsigned long)(PyObject *obj, unsigned long *val). 2) I merged the patch to SWIGINTERN int SWIG_AsVal_unsigned_SS_long (PyObject *obj, unsigned long *val), and replacing PyInt_AsUnsignedLongMask(obj) with PyLong_AsUnsignedLongMask(obj) since the PyInt_AsUnsignedLongMask(obj) is not defined. And found out that PyErr_Occurred() returns TRUE, thus the same error message as before. 3) I tried replacing "if (v >= 0) {" with "if (!PyErr_Occurred()) {" only. That seems working fine. ---------------------------------------------------------------------- Comment By: szager (szager) Date: 2011-10-28 21:13 Message: I can't reproduce this with 64-bit python, and I don't have a 32-bit python installation to try it with. Can you please try applying the patch attached to this bug, and let me know if it fixes the problem? ---------------------------------------------------------------------- Comment By: Hongbin Wei (weihongbin) Date: 2011-10-27 14:19 Message: Thanks Stefan. Here's the output of the commands. >>> platform.architecture() ('32bit', 'WinddowsPE') >>> platform.python_version() '3.2.0' ---------------------------------------------------------------------- Comment By: szager (szager) Date: 2011-10-27 11:52 Message: I have a proposed fix for this, but I'm unable to reproduce the problem. Can you please provide some details about the system you're running on: - Please send the output of this command: python -c 'import platform; print platform.architecture(); print platform.python_version()' - If you're on a linux system, please send the output of this command: uname -a Thanks, Stefan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=3429388&group_id=1645 |