(j3.2006) (SC22WG5.3591) Assumed-type and Assumed-rank extensions for C Interop TR.

Bill Long longb
Fri Jul 25 14:19:22 EDT 2008



Jim Xia wrote:
>
> j3-bounces at j3-fortran.org wrote on 07/25/2008 01:39:28 PM:
>
> > On Friday 25 July 2008 08:52, Jim Xia wrote:
> >
> > > And more, I don't understand this fragment
> > >
> > > type(*),target     :: block(*)
> > > integer(8)         :: nbytes
> > > Integer(8),pointer :: usable(:)
> > >
> > > call c_f_pointer (c_loc(block), usable, [nbytes*bit_size(usable)/8] )
> > >
> > > In particular, I don't understand what c_loc is used for since 
> block is
> > > already an address.
> > It is an assumed-shape ARRAY, not an address. We don't have that 
> concept nor
> > is anyone proposing we add it. It is passed by address, sure, but so 
> are
> > other assumed-shape arrays.
>
> block is an assumed-size array, not assumed-shape.  This fragment 
> doesn't demonstrate the "type casting" feature Bill is referring to. 
>  c_loc can be called on almost any types that is supported by C.

The result of the call, though, is that the pointer array USABLE is now 
associated with BLOCK.  USABLE does have a specific type, integer, and 
hence can be used in a wide range of statements.  This is unlike BLOCK, 
of type(*), that has very limited uses.


>
> >
> > > Also I don't see any type "casting" happens here as
> > > the example to demonstrate that.
> > You started with an array of unknown type, with which you can do
> > nothing. Then
> > you made a Fortran pointer of a known type (integer) point to it. 
> Now you can
> > do things with it. It is like doing:
> >
> > usable => block(1:nbytes/8)
>
> This brings another area you have to address: data pointer assignment. 
>  The type compatibility requirements need to modified to "enable" the 
> "type casting".  If an object of TYPE(*) is type compatible with 
> anything, but the reverse is not true, then this assignment is illegal 
> (similarly to the case that CLASS(*) target can not be pointer 
> assigned to an integer pointer, for instance.)  I can't find this in 
> Bill's paper.

Aleks did say "like doing".  Modifying the rules for pointer assignment 
is not in the paper.  Variables of type(*) are not allowed in that 
context. We already have the c_f_pointer option, and I was intentional 
in trying to minimize the impact on other parts of the standard in the 
TR.  If we wanted to add the pointer assignment rule changes in a future 
standard revision, the would be possible.  But it's not necessary to get 
the needed functionality. (Unless I missed something, which is possible.)

Cheers,
Bill

>
>
> Cheers,
>
> 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
> ------------------------------------------------------------------------
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>   

-- 
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 mailing list