Re: gfortran and the family of fortran array types

relaxmike <michael.baudin@xxxxxxxxx> wrote:

The fortran 90 array is declared as :

real(kind=C_FLOAT), dimension(:,:), allocatable, target :: mat

To be manageable by the C routine, a conversion must be done so that
only the base_addr field is passed to the C routine.

That is not so. Of course, prior to f2003, the standard didn't provide
any way at all to call C (or have the above C_FLOAT constant), but that
aside, there would be no problems at all with passing the above array to
C. It does *NOT* require the use of C_LOC.

You appear to be assuming that all arrays are inherently passed as dope
vectors, which is not so. I suspect that the confusion partly arises
from looking at argument passing conventions exactly backwards. To see
how an array is passed to a particular subroutine, you do *NOT* start
out by looking at the array in question. You start out by looking at the
interface of the subroutine. That's what defines the expected passing
mechanism.

If the subroutine has an assumed shape, pointer array, or allocatable
array dumy argument, then yes, something like a dope vector is likely to
get passed. But then a C function isn't going to have arguments like
that (unless someone went to a lot of work - and compiler-specific work
- just to make it that way).

If you just properly describe the interface of the C function, the array
will be passed properly, which is to say that just the starting address
will be passed. It does *NOT* matter that this array is allocatable.
That's a common error that people make, even without reference to C.
Just because an actual argument is allocatable, that doesn't mean that
the dummy argument has to be. (If a dummy argument is allocatable, then
th eactual argument must be, but that's a different matter). Once you
have allocated an allocatable array, it is now an array as "good" as any
other and it can be passed as an actual argument to procedures (or C
functions) that don't even need to know that it is allocatable. The same
applies to pointer arrays, I might add, though there is one slight
caveat to that case (involving the possibility that a pointer array
might point to a non-contiguous slice).

The fortran 2003
introduces the C_LOC operator for that purpose :

No. That is not the purpose of C_LOC. C_LOC is not needed at all in this
case. While you could use it, it is just redundant and needlessly
complicated for this case.

In the "Example of C calling Fortran" of the Reid pdf, p37, on the C
side, the array delta is declared with :

double delta[]

On the fortran side, the array is declared as :

REAL (C_DOUBLE),DIMENSION(*),INTENT(IN) :: DELTA

that is, with the fortran 77 syntax which corresponds to a
"assumed-size dummy array".

That's a different scenario from Fortran calling C.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
.

Relevant Pages

  • Re: Calling C from fortran
    ... An assumed shape array is declared with a syntax that looks like that of EPS above, but in the declaration of the dummy argument. ... this just indicates passing an array slice. ... There is no Fortran dummy argument declaration, so I tried to state some of the possible solution, ...
    (comp.lang.fortran)
  • Re: calling a function once works, calling it twice fails
    ... I have linked a C++-program with a fortran routine, ... end subroutine READ_DIMENSIONS ... Does your Fortran compiler have an option to check array subscripts? ...
    (comp.lang.fortran)
  • Re: Basic question on local variable
    ... which however is only available in Fortran 2003 and ... You may only use the VALUE attribute if the argument is not an array ... So, in fact, the better solution is to declare the dummy ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)
  • Calling a C routine from fortran
    ... I am facing the following issues in calling a C routine from fortran. ... array "dim" is assigned from in the file ...
    (comp.lang.fortran)
  • Speed versus memory
    ... My initial impulse was to use vector processes everywhere. ... an absurd amount of memory. ... Such a routine only has two input arrays ... and one output array but goes through ten intermediate arrays all of ...
    (comp.lang.fortran)