tags:

views:

115

answers:

4

I have a problem with passing of an array from Fortran to a c function: In the fortran the array is defined as

REAL(KIND=real_normal) , DIMENSION(:), ALLOCATABLE :: array
call cFunc(array)

If define the cFunc as

void cFunc(double *data){...}

Than the data contains only "garbage" values. Where is the problem in this case? (with integers works this solution well).

thx. EDIT: My platform: Compiler: VS 2008, Intel compiler 11 version OS: Win7

EDIT 2: I define the interface for the c-function like this (the code is reduced to one element, which makes problems, real function has more parameters):

interface c_interface

subroutine cFunc(array) bind (C, name = "cFunc")
use iso_c_binding
REAL(c_double), DIMENSION(*)::array
end subroutine cFunc

The memory in the fortran is allocated with

ALLOCATE (array(numberOfElements))
call cFunc(array)

At the moment i get an runtime error "Floating-point overflow". In some cases the array correct elements.

A: 

REAL might default to REAL*4 in which case you want a float* instead of double*.

Also make sure that you are prototyping the function before using it, otherwise C has a tendency to auto-promote floats to doubles in the absence of a reason not to. And make sure that you aren't taking a double and then taking an address of it and passing it "as" a float*.

eruciform
I cannot change the fortran code. So I have to adopt my C code. With float it doesn't work, too.
LonliLokli
For example with long double i get "Floating-point overflow." (i am using the intel-compiler for VS).
LonliLokli
double-check that (1) your prototype comes before your call in C, and (2) that the thing you're passing isn't a pointer to a different kind of float.
eruciform
A: 

Is real_normal 32-bit or 64-bit floating-point? What happens if you declare the function as void cFunc(float*data) ?

zvrba
win32, i get a runtime error after some accesses to the data.
LonliLokli
+4  A: 

The fragment REAL(KIND=real_normal) is not a complete and standard specification of a datatype. Somehwere in the source you have there must be a declaration of the variable real_normal. I'd guess that it is declared such that array is either 4- or 8-byte floating-point numbers, but that is only a guess. What array isn't is an array of default floating-point numbers (called real by Fortran).

As one of the other answerers has suggested, investigate the interoperability with C features of Fortran 2003. If your compiler doesn't implement these, ditch it and get a compiler that does.

High Performance Mark
+2  A: 

@High Performance Mark's suggestions are very good, and I highly recommend the ISO_C_Binding of Fortran 2003 (supported by numerous Fortran compilers) for interoperability between Fortran and C -- there is a larger issue here that makes the ISO_C_Binding more useful: Fortran allocatable arrays are more complicated then ordinary arrays. If you "hack it" and directly pass a pointer to the C code, you are likely to pass a pointer to a Fortran internal structure describing the allocatable array rather than a pointer to the sequence of numeric values. Allocatable arrays aren't directly supported by the ISO_C_Binding, but should work if you write an ISO_C_Binding interface (unlike what I wrote originally) -- the book "Fortran 95/2003 explained" says that the compiler will recognize the the called routine isn't receiving an allocatable array and will perform copy-in/copy-out to match the arrays.

P.S. My guess is that copy-in/copy-out shouldn't be necessary for a simple allocatable actual argument. When the compiler recognizes via an explicit interface (which could be an ISO_C_Binding interface) that the dummy argument of the called routine is not an allocatable, the compiler should just be able to extract the pointer to the actual array from the description of the allocatable and pass that as the argument. Copy-in/copy out will be required in some cases, such as a pointer to a non-contiguous array, such as pointer with a non-unit stride (e.g., a pointer that points to elements 1, 3, 5, ...). But without any interface, the compiler will likely pass the descriptor of the allocatable array, which won't be what C is expecting....

M. S. B.