This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Fortran-experiments] Bind(c) first experiences


i tested the code in my previous response with xlf95 (9.1) and it accepts 
the code with no warnings and no errors.  that is what gfortran 
currently does also.  i then added the line from Tobias' email ( 
type(c_funptr), pointer :: pnter ) as a local variable in sub0 and both 
xlf95 and gfortran still accept it.  

i've created a new testcase for this code, with a C main, and added them 
to the testsuite.  i'll submit them with the next patch.  

Chris

On Tue, 16 Jan 2007, Christopher D. Rickett wrote:

> to make a further comment on my statement below, consider the following 
> code:
> 
> module c_ptr_tests_3
> use, intrinsic :: iso_c_binding
> 
> type, bind(c) :: my_f90_type
>    integer(c_int) :: i
> end type my_f90_type
> 
> contains
>   subroutine sub0(c_struct) bind(c)
>     type(c_ptr), value :: c_struct
>     type(my_f90_type), pointer :: f90_type
> 
>     call c_f_pointer(c_struct, f90_type)
>   end subroutine sub0
> 
> end module c_ptr_tests_3
> 
> 
> currently, gfortran accepts this, and i think it is correct in doing so.  
> in reading section 15.1.2.2 on C_F_POINTER, the FPTR param (second arg) 
> "shall be a pointer.  It is an INTENT(OUT) argument."  Also, it says:
> 
> "(1)  If the value of CPTR is the C address of an interoperable data 
> entity, FPTR shall be a data pointer with type and type parameters 
> interoperable with the type of the entity..."
> 
> in the example i gave, i'm assuming c_struct is a struct that 
> interops with my_f90_type.  according to the draft, in order for 
> a derived type to be interoperable, it must have the BIND attribute 
> (section 15.2.3, line 2).  i think it is correct for the pointer to a 
> derived type to have the bind attribute, in some cases.  the pointer 
> attribute should not be allowed for a derived type decl if it is a dummy 
> arg to a bind(c) routine, i believe, but i'm not sure i'm checking this at 
> the moment...  i'm also not verifying that the second arg has the POINTER 
> attribute and has INTENT(OUT); i'll try and add these soon and submit a 
> patch.  
> 
> thoughts?
> Chris
> 
> 
> On Tue, 16 Jan 2007, Christopher D. Rickett wrote:
> 
> > 
> > 
> > > Thirdly,
> > >    type(c_funptr), pointer :: pnter
> > > is accepted, whereas NAG f95 gives me an error:
> > >    Error: test.f90, line 4: BIND(C) variable PNTER is a POINTER
> > > (I think NAG's error message is a bit misleading.)
> > > 
> > > I think this is prohibited; see F2003, 15.2.2 / 15.2.3:
> > > "C_PTR and C_FUNPTR shall be derived types with private components."
> > > "C1505  (R429)  Each component of a derived type with the BIND attribute
> > > shall be a nonpointer, nonallocatable data component with interoperable
> > > type and type parameters."
> > > 
> > 
> > i'm not sure whether the pnter declaration above should be prohibited or 
> > not.  i believe it is just fine as long as it is not a dummy arg trying to 
> > interop.  Tobias, what is the rest of the code?
> > 
> > Thanks.
> > Chris
> > 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]