Subject: CCL:Calling FORTRAN FUNCTIONS from a C-Program.

From: [email-masked] (Ron Shepard)
Date: Thu, 13 Oct 94 12:28:08 CDT

[email-masked] (Anil G. Mudholkar) wrote:
[...]
>	Regardless of what you want to do with your Fortran routines,
>you can always call them from C, and it is very simple.  Satisfy in
>the following conditions in the calling C functions:
>
>1.  All Fortran functions and subroutines have an underscore appended
>to their names.  i.e. Fortran subroutine foo() is C function foo_().
>
>2. All Fortran integers are passed by reference, while C integers are
>usually passed by value, 

It should be mentioned here that this is very machine dependent.  Not all
machines (fortunately or unfortunately, depending on your point of view)
work like Sun workstations.

>3. Fortran strings have no '\0' at the end, so your C function
>receiving the Fortran string will have to know what to do with it;
>either append a '\0' or just write n chars. 

Again, there is no standard portable way of mapping Fortran character
strings to C arrays.  Different machines use different conventions.

>4. General Fortran routines (math, etc) are in libF77.a (always link
>this), Fortran IO routines are in usually in libI77.a, and other
>Fortran routines are in libU77.a. (these are sometimes located in
>funny places, but usually /usr/lib, also some compilers like SunOS C
>stick everything in libF77.a, but add a libV77.a for a few other
>functions.)

Again, the number, names, and order of libraries is very machine
dependent. 

[...]
>I cannot speak to CFORTRAN having never
>seen it.

If portability is important, then this should be considered.  The
cfortran.h header file addresses the portability issues very well.  It
handles all of the tricky machine dependent stuff: integer/ real/ double
precision calling conventions, upper/lower case external name
conversions, prepending and/or appending the underscores where
appropriate, common blocks, character string conventions, etc.  The only
problem is with efficiency: cfortran.h works by constructing "glue"
interface modules and creating, when necessary, intermediate copies of
both scalars and array (primarily char) arguments.  Thus every function
reference grows into two references, with some possible malloc()
overhead.

$.02 -Ron Shepard