BUG: revise string_from_pyobj/try_pyarr_from_string with respect to malloc and copy (the second round) #19251
Conversation
…alloc and copy (the second round)
|
On that issue, I was a bit curious if f2py could actually shorten the string length passed to fortran (so it represents the actual length without any padding). That probably achieves the identical behavior as padding with spaces though. |
I think this would not work with intent(inout) or intent(out) arguments because if a Fortran program expects a fixed-length character string then f2py must provide memory with the required size (even when initially filled with blanks or nulls) because the Fortran program is allowed to write (read: index) to the string till the end of it. UPDATE: it would not even work for intent(in) arguments because the Fortran program is allowed to read (read: index) the fixed-width string till the end of it. |
|
Let's give this a shot. Thanks Pearu. |
Improved #18759 that was reverted by #19235 .
Originally, it was assumed that Fortran treats null values in byte-strings similar to C but that turned out to be wrong and caused failures in scipy tests that use f2py wrapped functions with string
intent(inout)arguments for Fortran fixed-width character string arguments.This PR (in addition to original changes) replaces the trailing nulls in strings with trailing blanks that Fortran treats as "null values" and when Fortran program returns a string with trailing blanks, these will be replaced with trailing nulls because the content of numpy ndarray of strings is interpreted as C strings.
Fixes #18431 (again) and #19201 .
This PR is tested against the current scipy master: all scipy tests pass ok.