Calling FORTRAN from C (Was: Need matrix inversion C routine).

[Herman Rubin]

In article <1544 at auspex.auspex.com>, guy at auspex.auspex.com (Guy Harris) writes:
> >There are two problems.  Each implementation of a language will have its
> >calling sequence.  This problem is unavoidable, and can be a major headache.
> 
> ...
> 
> >The bigger problem is names.
> 
> No, there are at least three problems.  The third problem is the
> representation of the language's data types, unless you consider that a
> subclass of the first problem.  Passing a C character string to a
> routine expecting a FORTRAN character string may not work, nor will
> passing an integer value by reference, FORTRAN-style, to a routine
> expecting it to be passed by value, C-style.

I see this as part of the calling sequence problem.  Certainly, for a 
Fortran program to call a C program which expects values rather than
references, the Fortran program must pass the parameters as it knows
how C expects to find them.  This might involve considerable work with
complicated data structures, but presumably these matters are problems
of the language and not of the implementation.

> >It should be considered essential that any user be able to access any
> >object program compiled by any processor by proper use of the calling
> >sequence and return, and this means knowing the system name of the program
> >and being able to instruct the compiler that a program with that name is
> >to be called.
> 
> Well:
> 
> 	1) that's not something within the purview of either the C or
> 	   FORTRAN standard, since it requires particular implementation
> 	   choices to be made for both languages; it falls between two
> 	   chairs, and touches on an area that standards committees
> 	   often try to avoid constraining, namely implementations. 
> 	   It's not within the purview of POSIX, either.

I have used several operating systems before UNIX.  On all of them, a name
was a name was a name.  The program cards and subroutine cards in Fortran
produced names in the object file identical to what appeared on the card.
Entry names and COMMON block names likewise.  Assembler-produced programs
did the same thing.  If I was going to use an Algol program it would still
be the same.  The calling sequence was a problem, even between Fortrans.
But not the names.

Speaking of names, why should one not be able to name a main program?

> 	2) given the "third problem", you may have to write a "jacket"
> 	   routine to translate data types, which means that it may not
> 	   necessarily be useful merely to patch up the name-space
> 	   problem, since you can't just call, say, the UNIX "open"
> 	   routine from FORTRAN in the same way you can call it from C.

There is no reason why the calling sequence for a subroutine to be called
from Fortran shoulc be the Fortran calling sequence.  But the Fortran 
compiler should, if necessary, have a patch to produce the necessary
calling sequence.

> I don't have Stu Feldman's paper on F77 handy, so I don't know if he put
> in the prepended underscore, in part, to allow you to have a jacket for
> the C routine "foobar" written in C and called "foobar_" from within C
> and thus "foobar" from within FORTRAN, that does any requisite data type
> translations.

This assumes that the writer of the C program writes it so it can be called
"foobar" from within Fortran on this particular type of system.  On our extinct
system, we did have a version of F77, but it did not use underlines at all.
Now suppose that we have an excellent program "foo" written in C, and the
object file is in the library.  Why should I not be able to use this program
from Fortran without recompiling it.  Or even if I have a full graphics
package of subroutines, why should this not be callable from any processor
regardless of its name?

A calling sequence requiring data editing is relatively easy.  On every
implementation I have used, I do know how to hack the .s program to change
the names, but can every user of a subroutine I provide be required to do so?
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin at l.cc.purdue.edu (Internet, bitnet, UUCP)