C_LOC and character string
in [Fortran]
|
Prev: Problems matching between FORTRAN COMMON and C struct defined in a dll
Next: Problems matching between FORTRAN COMMON and C struct defined in a ?dll
From: M.S. Breitenfeld on 30 Mar 2010 12:13 I think this is a standard complaint code and about as simple as it gets, but the xlf2003 compiler gives the error: "test.f90", line 19.15: 1516-169 (S) A variable that is specified as an argument to the intrinsic procedure C_LOC must either have type and type parameters that are interoperable with a C type, or be a nonpolymorphic, scalar variable with no length type parameters. program main use iso_c_binding character(LEN=80, kind=c_char),target :: ichr type(C_PTR) :: f_ptr ichr = "test" f_ptr = C_LOC(ichr(1:1)) end
From: Richard Maine on 30 Mar 2010 12:29 M.S. Breitenfeld <msbrtnfld(a)gmail.com> wrote: > I think this is a standard complaint code and about as simple as it > gets, but the xlf2003 compiler gives the error: > > "test.f90", line 19.15: 1516-169 (S) A variable that is specified as an > argument to the intrinsic procedure C_LOC must either have type and type > parameters that are interoperable with a C type, or be a nonpolymorphic, > scalar variable with no length type parameters. > > program main > > use iso_c_binding > > character(LEN=80, kind=c_char),target :: ichr > type(C_PTR) :: f_ptr > > ichr = "test" > > f_ptr = C_LOC(ichr(1:1)) > > end Well, I wouldn't say it is quite as simple as it gets. Your ichr is not interoperable, which slightly confuses matters. (Yes, you can pass ichr as an actual argument to a C function, but that is not quite the same thing - related, but not the same). But ichr(1:1) is interoperable. So yes, the code looks legit to me. I agree with you on that. My only argument was about it being "as simple as it gets". Both nag and g95 compile it without complaint. This is not definitive evidence, but it at least helps in case I missed something obvious. Hmm. Let's make the help slightly more convincing. If I edit it to ask for C_LOC(ichr) instead of using the substring, then both nag and g95 complain that the length needs to be 1. That verifies that both those compilers are at least trying to check this condition. It still isn't definitive, but it provides slightly more weight. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: M.S. Breitenfeld on 30 Mar 2010 12:42 > > Both nag and g95 compile it without complaint. This is not definitive > evidence, but it at least helps in case I missed something obvious. Hmm. > Let's make the help slightly more convincing. If I edit it to ask for > C_LOC(ichr) instead of using the substring, then both nag and g95 > complain that the length needs to be 1. That verifies that both those > compilers are at least trying to check this condition. It still isn't > definitive, but it provides slightly more weight. > I also tested it with sun's compiler, intel's, and gfortran (which also complains if I remove (1:1) ) with no problems, so between us I think that covers most of the compilers :) My understanding was the same as yours, that ichr(1:1) is interoperable and it should not be giving a fatal error. I just wanted to make sure I was not missing something. Guess I will have to do some rewriting.
From: Steve Lionel on 30 Mar 2010 19:48 On 3/30/2010 12:42 PM, M.S. Breitenfeld wrote: > I also tested it with sun's compiler, intel's, and gfortran (which also > complains if I remove (1:1) ) with no problems, so between us I think > that covers most of the compilers :) My understanding was the same as > yours, that ichr(1:1) is interoperable and it should not be giving a > fatal error. I just wanted to make sure I was not missing something. > Guess I will have to do some rewriting. I will comment that the Intel compiler does not give a warning under any cirumstances if the argument to C_LOC is not interoperable. (The standard does not require this diagnosis.) My understanding of the matter matches Richard's, however. -- Steve Lionel Developer Products Division Intel Corporation Nashua, NH For email address, replace "invalid" with "com" User communities for Intel Software Development Products http://software.intel.com/en-us/forums/ Intel Software Development Products Support http://software.intel.com/sites/support/ My Fortran blog http://www.intel.com/software/drfortran
From: Jim Xia on 31 Mar 2010 11:21
On Mar 30, 12:13 pm, "M.S. Breitenfeld" <msbrtn...(a)gmail.com> wrote: > I think this is a standard complaint code and about as simple as it > gets, but the xlf2003 compiler gives the error: > > "test.f90", line 19.15: 1516-169 (S) A variable that is specified as an > argument to the intrinsic procedure C_LOC must either have type and type > parameters that are interoperable with a C type, or be a nonpolymorphic, > scalar variable with no length type parameters. > > program main > > use iso_c_binding > > character(LEN=80, kind=c_char),target :: ichr > type(C_PTR) :: f_ptr > > ichr = "test" > > f_ptr = C_LOC(ichr(1:1)) > > end This seems to be a bug in XLF compiler, and the bug has been reported to the XLF compiler team. The only comment I'd like to make here is: in general substring of ichr, i.e. ichr(l:m), is not interoperable with C, as Richard has commented. The relevant text of the F03 standard is quoted as follows Clause 15.2.1 " if the type is character, inter 6 operability also requires that the length type parameter be omitted or be specified by an initialization 7 expression whose value is one." Strictly speaking, I'm not convienced "ichr(1:1)" is interoperable by this restrictive definition since it is not declared as what the standard requires. Thanks Jim |