PyLong to std::size_t conversion overflows
Conversion from PyLong
to std::size_t
fails for values >= 2**63
on 64-bit machines. The key of the problem is in dolfin/swig/typemaps/primitives.i:Py_convert_std_size_t
. Solution of the problem should probably wait until Py3 transition is finished.
MWE:
from dolfin import *
m = UnitIntervalMesh(1)
f = CellFunction('size_t', m)
f[0] = 2**63
# TypeError: (size_t) expected positive 'int' for argument 3
Comments (19)
-
-
reporter What about testing with py3? Is it handled by buildbots, @johannes_ring?
Is somewhere written what python versions do we support?
-
@blechta - Yes, we have a buildbot running Python 3.
-
FEniCS dev requires 2.7, and the py3 buildbot passes all but a few tests. Some of the failures are a bit weird and may or may not be hard to debug. Feel free to look at them.
-
reporter And which is the lowest py3 version required?
-
I don't know. I think Aslak used 3.2 while I've used 3.4. @johannes_ring what 3.x does the buildbot use?
-
@martinal - 3.4, the one in Ubuntu 14.04.
-
@blechta we haven't discussed which 3.x version to require, but I think there are minor issues that are more compatible between 2.7 and 3.2 than with 3.0 and possibly 3.1, so requiring 3.2 makes sense. For all I care it's just as well to just jump straight to 3.4. Personally I'll stick with 2.7 for now, as 3.x seems a lot slower.
-
reporter - changed status to resolved
Fix issue 377 - conversion of large PyLong to size_t.
→ <<cset 7530d4f31f98>>
-
reporter Fix in pull request #162. Nevertheless some strange issues persist
from dolfin import * import numpy as np m = UnitIntervalMesh(1) f = CellFunction('size_t', m) f[0] = np.uintp(2**63 - 1) print f[0] == 2**63 - 1 # True print f[0] == np.uintp(2**63 - 1) # True print f[0] == np.uintp(2**63 - 512) # True!!! print f[0] == np.uintp(2**63 + 1024) # True!!! f[0] = 2** 64 - 1 # now working print f[0] == 2**64 - 1 # True f[0] = np.uintp(2** 64 - 1) # not yet working
-
reporter - changed status to open
Fix in pull request #162.
-
I have now fixed the last conversion. We needed to treat numpy integers different to Python ints, at least for Python 2. Will push and merge as soon as it passes local tests.
-
@johanhake Is this now resolved?
-
- changed milestone to 1.5
-
reporter It is not. Third and fourth print statement from the example still print True.
-
- changed milestone to 1.6
-
- changed milestone to 1.7
-
- removed milestone
Removing milestone: 1.7 (automated comment)
-
- changed status to wontfix
This will be dealt with by
#897. - Log in to comment
There are no outstanding py3 branches, feel free to fix away.