Repository navigation
BUG: Fix f2py string variables in callbacks. - #10031
Conversation
charris
added
00 - Bug
09 - Backport-Candidate
|
Test added. |
charris
changed the title
When NPY_CHAR was deprecated and replaced by NPY_STRING in f2py, calls to PyArray_New that previously relied on the type to get the itemsize needed the size explicitly specified, but that modification was missed in some of the code. Because the strings that replacee the 'c' type are always 'S1', we use an itemsize of 1 for the string types and pass it explicitly. Closes numpy#10027.
e63f872 to
0a1069a
Compare
charris
changed the title
charris
changed the title
|
Hmm, I think I uncovered a different error with the test. Will be fooling with stuff for a bit. |
206d8e7 to
012ad9f
Compare
|
Should be good to go. |
| return 2 | ||
| if not np.all(cu == b''): | ||
| return 3 | ||
| return 0 |
There was a problem hiding this comment.
I'm curious - what happens if you use assert in here directly? Can f2py forward the exception?
There was a problem hiding this comment.
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.
|
Putting in for backport. |
| 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; |
There was a problem hiding this comment.
Is there any way that VOID or UNICODE can end up here? They might need a similar fix, if so.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
2 participants
When NPY_CHAR was deprecated and replaced by NPY_STRING in f2py, calls
to PyArray_New that previously relied on the type to get the itemsize
needed the size explicitly specified, but that modification was missed
in some of the code. Because the strings that replaced the 'c' type are
always 'S1', we use an itemsize of 1 for the string types and pass it
explicitly.
Closes #10027.