Link Copied
Thank you very much for your answer, IanH.
You are totally right about the missing deallocate. I was probably wanting to do it right after the
call f_c_pointer(fptr, cptrres, [STRLEN])bit I was dreaming of, but even there, it doesn't seem right, does it ?
About the standard :
I understand that A) we are obviously not in the (ii) case, and that we are also not in the case (i) because in "If the value of CPTR is the C address of an interoperable data entity" the term "data entity" refers to a Fortran data entity (am I right) so that elimination we are indeed in the case (iii). Correct ?
Then, reading case (iii), it seems that what you do (the associating *_ptr's to *_str's) work by the very standard, hence I don't understand your "case (iii) of F2018.18.2.3.3p3 probably lets us get away with this, perhaps in a processor dependent fashion'. Where do I make a mistake ?
Also, I am very interested by your "do the whole c_f_pointer-associate-cptr-with-a-len(1)-array-then-argument-associate-the-resulting-array-with-a-len(x)-scalar-using-sequence-association" trick : could you please develop a bit, or point me to a reference ? (Btw, I am really short in Fortran idioms/patterns/concepts (like this trick you mention, or the opaque pointer method I read about this night) so that, would you have references about that, I would be happy.)
Concerning your solution and memory, I am correct to sum it up like this :
- python allocates memory for b'Hello World' and in_ptr points to (the beginning of) it
- this pointer is passed byreference to the fortran subroutine
- memory is allocated inside upper_fortran for the out c_char arry
? So that we could say that, all in all, your solution makes only one string copy ?
Is a solution with no out_ptr and only modification of in_str (with a subroutine upper_fortran (instead of a function) modyfing in and outing it) possible ?
(Forum also ate my reply, it is really boring ... Now, by out of angst, I will have to copy paste my replies and questions in a notepad, in case of forum eating them ...)
Thank you very much for your answer, IanH.
Regarding the missing matching deallocate you are perfectly right. I intented to make it right after the
call f_c_pointer(fptr, cptrres, [STRLEN])I was dreaming about. But even there, it does not feel right, doesn't it ?
Regarding the standard :
Obviously were not in the case (ii). Also, we are a not in the case (i) as I guess that an "interoperable data entity" is irst a Fortran entity, which is not the case here as we pass a Python object to Fortran. Hence by elimination we are in the case (ii). Correct ?
Now, about case (iii) of F2018 18.2.3.3 :
"If the value of CPTR is the C address of a storage sequence that is not in use by
any other Fortran entity, FPTR becomes associated with that storage sequence.
If FPTR is an array, its shape is specified by SHAPE and each lower bound
is 1. The storage sequence shall be large enough to contain the target object
described by FPTR and shall satisfy any other processor-dependent requirement
for association."
I understand that there is no problem at all, so that I don't get your "case (iii) of F2018 18.2.3.3p3 probably lets us get away with this, perhaps in a processor dependent fashion".
Could you please consider developing on your "c_f_pointer-associate-cptr-with-a-len(1)-array-then-argument-associate-the-resulting-array-with-a-len(x)-scalar-using-sequence-association" trick ? By the way, I am quite ignorant of classical idioms/patterns/tricks (like the one you refer to, or like the opaque pointer trick I learned about this night) so that if you have reference(s) regarding this, I would be happy.
On the memory aspect of your code, am I right to summerize it as follows :
- python allocates memory for b'Hello World' and a pointer pointing to (the beginning of) it
- this is passed by reference (meaning bu that "no copy is created"
- In the function upper_fortran, the line
creates memory for the returning "string"character(len=len(in),kind=c_char) :: out - this string is returned by reference to the python
?
Also, is it possible to in your upper_python subroutine not to have the out_ptr, but just have the in_ptr, in an "inout" fashion ?
The description by @IanH and the example provided is generally the way to go for safe programming with Fortran, particularly in mixed-language solutions.
As you have noted the interoperability of Python using ctypes is with C and as you know, the language standard for Fortran too follows the interoperability with a C companion processor. Given this, it's often the case C programming idioms and style come into the mix. Starting with the seminal work by Kernighan and Ritchie, the lessons and examples imparted widely with C programs do tend to lean toward heavy use of pointers and a function to upper case a string might be written as below where the char case conversion is in situ and no copying is involved:
char *strupr(char s[])
{
char *p;
for (p = s; *p; ++p)
*p = toupper(*p);
return(s);
}
So now, if what you are trying is influenced by such an approach and you do think you need to provide such functions in Fortran for consumption on the Python side, then caveat emptor with a Fortran snippet below!
module Fdll_m
use, intrinsic :: iso_c_binding, only : c_size_t, c_char, c_ptr, c_null_ptr, c_loc, c_f_pointer
contains
function to_upper(s, lens) result(sptr) bind(C, name="to_upper")
! Argument list
character(kind=c_char,len=1), intent(in), target :: s(*)
integer(c_size_t), intent(in), value :: lens
! Function result
type(c_ptr) :: sptr
sptr = c_null_ptr
if ( lens > 0 ) then
sptr = c_loc(s)
block
character(kind=c_char,len=lens), pointer :: str
integer :: I, K
integer, parameter :: CASE_OFFSET = iachar('a') - iachar('A')
call c_f_pointer( cptr=sptr, fptr=str )
do I = 1, lens
K = iachar( str(I:I) )
if ( K >= iachar('a') .and. K <= iachar('z') ) then
K = K - CASE_OFFSET
str(I:I) = achar(K)
end if
end do
end block
end if
end function
end module Fdll_m
where a basic aspect of safety and convenience is brought in by including a function parameter toward length of the string (c.f. the message by @Steve_Lionel you referenced) but otherwise it follows in rather verbose Fortrannic fashion the style of C of a "long rope to shoot oneself in the foot".
Assuming the above Fortran snippet is compiled using /libs:static and the resultant DLL is on one's Windows OS PATH (e.g., in "C:\xx\yy\bin" folder where one may place one shared library objects and which is specified first/earlier on in the environment settings), the function can be consumed in Python like so:
import ctypes
# Load the Fortran DLL; ensure it's on the PATH
Fdll = ctypes.CDLL('Fdll.dll')
# Specify the interface toward the Fortran function
Fdll.to_upper.restype=ctypes.c_char_p
Fdll.to_upper.argtypes=[ctypes.c_char_p, ctypes.c_size_t]
# Create a "mutable" ctypes string buffer
s = ctypes.create_string_buffer(b"modern fortran",15)
# Invoke the Fortran function
s = Fdll.to_upper(s, len(s))
# Output the modified "string"
print(s)
Running above, the output produced is
