Skip to content

BUG: Fix f2py string variables in callbacks. #10031

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Nov 18, 2017
Merged

BUG: Fix f2py string variables in callbacks. #10031

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0a1069a
BUG: Fix f2py string variables in callbacks.
charris Nov 15, 2017
012ad9f
TST: Test f2py passing string array to callback.
charris Nov 15, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions numpy/f2py/cb_rules.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -367,11 +367,15 @@
'pyobjfrom': [{debugcapi: '\tfprintf(stderr,"debug-capi:cb:#varname#\\n");'},
{isintent_c: """\
\tif (#name#_nofargs>capi_i) {
\t\tPyArrayObject *tmp_arr = (PyArrayObject *)PyArray_New(&PyArray_Type,#rank#,#varname_i#_Dims,#atype#,NULL,(char*)#varname_i#,0,NPY_ARRAY_CARRAY,NULL); /*XXX: Hmm, what will destroy this array??? */
\t\tint itemsize_ = #atype# == NPY_STRING ? 1 : 0;
\t\t/*XXX: Hmm, what will destroy this array??? */
\t\tPyArrayObject *tmp_arr = (PyArrayObject *)PyArray_New(&PyArray_Type,#rank#,#varname_i#_Dims,#atype#,NULL,(char*)#varname_i#,itemsize_,NPY_ARRAY_CARRAY,NULL);
""",
l_not(isintent_c): """\
\tif (#name#_nofargs>capi_i) {
\t\tPyArrayObject *tmp_arr = (PyArrayObject *)PyArray_New(&PyArray_Type,#rank#,#varname_i#_Dims,#atype#,NULL,(char*)#varname_i#,0,NPY_ARRAY_FARRAY,NULL); /*XXX: Hmm, what will destroy this array??? */
\t\tint itemsize_ = #atype# == NPY_STRING ? 1 : 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any way that VOID or UNICODE can end up here? They might need a similar fix, if so.

Copy link
Member Author

@charris charris Nov 18, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. My thought was that we will need to wait and see, the original was always defaulting. Fortran added a UCS-4 type in 2003 (name ISO_10646), but I do not see that in the current f2py. If/when we add that functionality we will need to revisit this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Support for UCS-4 seems rather sporadic, it wasn't required until 2008. I expect utf-8 will eventually show up, but Fortran seems wedded to fixed width strings (like the NumPy S and U types) so I don't expect that to happen anytime soon.

\t\t/*XXX: Hmm, what will destroy this array??? */
\t\tPyArrayObject *tmp_arr = (PyArrayObject *)PyArray_New(&PyArray_Type,#rank#,#varname_i#_Dims,#atype#,NULL,(char*)#varname_i#,itemsize_,NPY_ARRAY_FARRAY,NULL);
""",
},
"""
Expand Down
34 changes: 32 additions & 2 deletions numpy/f2py/tests/test_callback.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
import textwrap
import sys

from numpy import array
import numpy as np
from numpy.testing import run_module_suite, assert_, assert_equal, dec
from . import util

Expand Down Expand Up @@ -48,6 +48,16 @@ class TestF77Callback(util.F2PyTest):
a = callback(r)
end

subroutine string_callback_array(callback, cu, lencu, a)
external callback
integer callback
integer lencu
character*8 cu(lencu)
integer a
cf2py intent(out) a

a = callback(cu, lencu)
end
"""

@dec.slow
Expand Down Expand Up @@ -120,7 +130,8 @@ def mth(self):
r = t(a.mth)
assert_(r == 9, repr(r))

@dec.knownfailureif(sys.platform=='win32', msg='Fails with MinGW64 Gfortran (Issue #9673)')
@dec.knownfailureif(sys.platform=='win32',
msg='Fails with MinGW64 Gfortran (Issue #9673)')
def test_string_callback(self):

def callback(code):
Expand All @@ -133,6 +144,25 @@ def callback(code):
r = f(callback)
assert_(r == 0, repr(r))

@dec.knownfailureif(sys.platform=='win32',
msg='Fails with MinGW64 Gfortran (Issue #9673)')
def test_string_callback_array(self):
# See gh-10027
cu = np.zeros((1, 8), 'S1')

def callback(cu, lencu):
if cu.shape != (lencu, 8):
return 1
if cu.dtype != 'S1':
return 2
if not np.all(cu == b''):
return 3
return 0
Copy link
Member

@eric-wieser eric-wieser Nov 16, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious - what happens if you use assert in here directly? Can f2py forward the exception?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't know, I was tempted but figured to play safe ... Yes, that works. The fortran subroutine doesn't catch the error, rather the call wrapper does a longjmp to an error return from the fortran subroutine C wrapper.


f = getattr(self.module, 'string_callback_array')
res = f(callback, cu, len(cu))
assert_(res == 0, repr(res))


if __name__ == "__main__":
run_module_suite()