(j3.2006) (SC22WG5.3593) Assumed-type and Assumed-rank extensions for C Interop TR.
Fri Jul 25 18:37:52 EDT 2008
Jim Xia wrote:
> Bill Long <longb at cray.com> wrote on 07/25/2008 02:38:50 PM:
> > > The basic problem is Fortran side can not use this type directly. If
> > > the procedure is defined in Fortran for C, then how can a Fortran
> > > programmer "map" this dummy argument to real Fortran data type.
> > In what way does C_F_POINTER fail to solve this problem? It was
> > explicitly designed to be used on the Fortran side to give a Fortran
> > type, type parameters, and shape to a block of memory pointed to by a C
> > address.
> Read what's written in C_F_POINTER on page 394
> (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 this case, FPTR
> becomes pointer associated with the target of CPTR. If FPTR is
> an array, its shape is specified by SHAPE and each lower bound
Option 1 is the one we want to apply. If the wording of the draft is
such that these conditions are not met, then fixes are needed.
> In any case, it is asking for the pointer association. I don't see
> how TYPE(*) can fit in here yet.
The FPTR argument was declared integer,pointer,dimension(:), so it is
clearly a pointer. The effect of executing c_f_pointer is to cause that
pointer to be associated with the target of CPTR, which in this case is
the buffer that was declared type(*). C_F_POINTER does not ask for
pointer association, it causes pointer association.
> Jim Xia
> RL Fortran Compiler Test
> IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7
> Phone (905) 413-3444 Tie-line 313-3444
> email: jimxia at ca.ibm.com
> D2/YF7/8200 /MKM
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
More information about the J3