For some target languages (Octave, Python and Ruby), SWIG has previously
treated nullptr or NULL as an integer 0 if used in a situation where
the type wasn't known to be a pointer.
For nullptr this is never helpful, because it has type nullptr_t which
does not implicitly convert to 0, so we no longer do this.
For NULL it's rather dubious - C and C++ allow NULL to be defined as
integer 0, so `int i = NULL` may work and is occassionally seen in real
code, but it is semantically wrong. Also GCC and clang define NULL to a
magic value and by default will warn about such misuse, so it's likely
to be less common than before they did this. So now SWIG only converts
NULL to 0 if used in a context where we know the underlying type is an
arithmetic type.
Using an integer zero (or equivalent value such as 0L) for a NULL
pointer is valid, and SWIG will still treat it as a NULL pointer if used
in a context where know the type is a pointer. This is now done based
on the value of the integer constant so also applies to 0L (previously
it was only done if the value was written in the code as literally `0`).
Fixes: #3472
Fix handling of "default" typemap applied to method which takes a
single argument when "-builtin" option is used.
Fixes#2786Closes#2790Closes#3241Closes#3243
Co-authored by @ojwb who also suggested it in discussion of #2790.
Use Python class staticmethod syntax to access C++ static member functions,
such as Klass.memberfunction, instead of Klass_memberfunction.
Examples and test-suite changes in preparation for issue #2137.
There were only needed to support Python < 2.2, and we now require at
least Python 2.6.
Conflicts:
.travis.yml
Examples/test-suite/python/autodoc_runme.py
Source/Modules/python.cxx
This is a cherry-pick and merge from patch in #1261
Specifying the minimum 32 bit signed int value is not easily portable.
Remove min_32bit_int2 method, min_32bit_int1 provides runtime coverage.
g++ 32bit resulted in:
warning: this decimal constant is unsigned only in ISO C90
and some versions of clang++ resulted in:
error: integer literal is too large to be represented in type 'long' and is subject to undefined behavior under C++98, interpreting as 'unsigned long'; this literal will have type 'long long' in C++11 onwards [-Werror,-Wc++11-compat]
32 bit and 64 bit compiled versions of SWIG generated different Python files
when default arguments were outside the range of 32 bit signed integers.
The default arguments specified in Python are now only those that are in the
range of a 32 bit signed integer, otherwise the default is obtained from C/C++ code.
Closes#1108
1. Fix negative octals. Currently not handled correctly by `-py3`
(unusual case, but incorrect).
2. Fix arguments of type "octal + something" (e.g. `0640 | 04`).
Currently drops everything after the first octal. Nasty!
3. Fix bool arguments "0 + something" (e.g. `0 | 1`) are always
"False" (unusual case, but incorrect).
4. Remove special handling of "TRUE" and "FALSE" from
`convertValue` since there's no reason these have to match
"true" and "false".
5. Remove the Python 2 vs. Python 3 distinction based on the
`-py3` flag. Now the same python code is produced for default
arguments for Python 2 and Python 3. For this, octal default
arguments, e.g. 0644, are now wrapped as `int('644', 8)`. This
is required, as Python 2 and Python 3 have incompatible syntax
for octal literals.
Fixes#707
Don't skip checking subsequent arguments just because one of them has "in"
typemap with numinputs=0 attribute.
Add a unit test showing the problem which is relatively rare as it doesn't
happen for the class methods and is hidden unless autodoc feature is used for
the global functions.
Closes#377.
Use "compact" arguments form for the function if "default" typemap is defined
for any of its arguments to allow omitting this argument when calling it from
Python.
Closes#377.
Accept not only manifest pointer types (such as e.g. "void *") but also types
that are typedefs for pointer types when checking whether C++ value of 0 must
be represented as 0 or None in Python.
Closes#365, #376.
Default values are no longer generated as Python code by default.
They must be explicitly turned on using the "python:defaultargs" feature.
Closes#294Closes#296
The problems in these two issues when "python:defaultargs" is turned
on still need to be fixed and should be addressed in separate patches.
The important thing is the default code generation is now fixed.
Enum values are just (integer) constants in Python and so can be used as the
function default values just as well as literal numbers, account for this when
checking whether function parameters can be represented in Python.
Also rename is_primitive_defaultargs() to is_representable_as_pyargs() to
describe better what this function does.
Olly Betts