Re: C binding

[Tobias Burnus <burnus at net-b dot de>]

Hi Salvatore,

Salvatore Filippone wrote:
> My copy of MR&C says that the c_loc intrinsic may be applied to (case
> ib) "an allocated allocatable variable that has the target attribute
> and is not an array of zero size",
The Fortran 2003 standard has:

Argument. X shall either
(1) have interoperable type and type parameters and be
    (a) a variable that has the TARGET attribute and is interoperable,
    (b) an allocated allocatable variable that has the TARGET attribute
and is not an array of zero size, or
    (c) an associated scalar pointer, or
(2) be a nonpolymorphic scalar, have no length type parameters, and be [...]


And after some reading I agree that it is a bug, see PR 33497.

 * * *

>   type double_vector_item
>     real(kind(1.d0)), allocatable :: v(:)
>   end type double_vector_item
>   type(double_vector_item), allocatable, target :: dbv_pool(:)
>
>       get_double_vector_address = c_loc(dbv_pool(handle)%v

At a glance, it looks ok (assuming that REAL(kind(1d0)) is
"interoperable"); the V(:) component has also the target attribute (not
directly as TARGET is not allowed for TYPE components, but indirect as
dbv_pool is a TARGET [5.1.2.14 TARGET attribute]: "If an object has the
TARGET attribute, then all of its nonpointer subobjects also have the
TARGET attribute"). Thus I don't see any reason why (1b) should not
apply. An additional hint that this is a bug in gfortran is that NAG
f95, g95 and ifort 10 accept this program; sunf95 seems to have the same
problem.

Note that the following program works:

real(kind(1d0)), allocatable, target :: v(:)
      get_double_vector_address = c_loc(v)

which is effectively identical - even though verify_c_interop rejects
the former but accepts the latter.

Tobias