* Python: Fix warnings about implicit type conversions
When compiling with -Wconversion -Wsign-conversion on
gcc, these places resulted in warnings.
Add explicit type casts to be clear to the compiler.
* new_copy_array casts size to size_t
This alleviates warnings when -Wconversion -Wsign-conversion
are enabled.
* Fix various conversions to correct integer signedness
len can be signed as is the case with python's size_t.
This casts it to size_t to avoid compilation warnings.
* Add -Wconversion and -Wsign-conversion compilation flags for tests
- Comment how and why LONG_MAX/ULONG_MAX is replaced by
long_max/ulong_max.
- Use our conventional approach to detecting Python version in testcases.
- Convert use of testcase assert.
In SWIG_CanCastAsInteger, we check for double(value) <= double(LONG_MAX).
However LONG_MAX cannot be represented as double if sizeof(long)=8, so it is usually rounded
to LONG_MAX+1. So SWIG_CanCastAsInteger returned true for LONG_MAX+1 and the next cast ended
up in an integer overflow.
Worse for unsigned long: It is called by smaller unsigned integers with range checks after
the convertion to unsigned long. As the integer overflow yields a 0x0, this is valid for all
small unsigned integers. Smaller signed integers will always fail this range check after the
integer overflow.
This fixes the tests on my machine:
as_l(lmaxd + LSB)
as_ll(llmaxd + LSB)
as_ul(ulmax + LSB)
as_ull(ullmax + LSB)
Wrong old results before this commit:
as_l(float(2**63)) := -0x8000000000000000
as_ll(float(2**63)) := -0x8000000000000000
as_uc(float(2**64)) := 0x0
as_us(float(2**64)) := 0x0
as_ui(float(2**64)) := 0x0
as_ul(float(2**64)) := 0x0
as_ull(float(2**64)) := 0x0
Now all of them throw an exception.
This is especially important for the unsigned long typemap, which is used by
the size_t typemap, which is in turn used for lengths of std containers etc.
In Python2, len requires old-style classes' __len__ method return a PyIntObject
rather than a PyLongObject, so this supports that requirement.
Adds preprocessor checks to avoid defining functions that use long long if it isn't available
Effects the following languages: javascript, octave, perl, python, r, ruby, tcl
Don't mistakenly treat PyLong objects as PyInt objects in Python3.
This resolves issues of large integers being incorrectly treated as -1 while also having
an OverflowError set internally for converting PyLong->long and PyLong->double
Conversions from PyLong to long, unsigned long, long long, and unsigned long long now
raise OverflowError rather than TypeError when given an out of range value.
Removing unnecessary check for PyLong_AsLong when converting PyLong->unsigned long since the
call to PyLong_AsUnsignedLong will have covered this case.
The typemap incorrectly called PyInt_AsLong() if PyInt_Check() passed, but
this check is the same as PyLong_Check() for Python 3 and so the correct
PyLong_AsUnsignedLong() function was never called. As a consequence, passing
any value greater than LONG_MAX (e.g. 0x87654321 on 32 bit architectures) to a
function taking unsigned int, unsigned long or size_t parameter failed with an
overflow error being generated.
Fix this by simply disabling the part of the code dealing with PyInts for
Python 3 as there is no distinction between PyInt and PyLong there any more.
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@13877 626c5289-ae23-0410-ae9c-e8d60b6d4f22
Julien Schueller