(j3.2006) (SC22WG5.3591) Assumed-type and Assumed-rank extensions for C Interop TR.
Fri Jul 25 14:05:37 EDT 2008
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
> > already an address.
> It is an assumed-shape ARRAY, not an address. We don't have that concept
> 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.
> > 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
> 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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the J3