Xref: utzoo comp.lang.c:18273 comp.lang.fortran:1998
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.c,comp.lang.fortran
Subject: Re: Calling FORTRAN from C (Was: Need matrix inversion C routine).
Summary: The main problem is that of names
Message-ID: <1274@l.cc.purdue.edu>
Date: 2 May 89 13:49:17 GMT
References: <2846@tank.uchicago.edu> <5785@cbnews.ATT.COM> <10087@smoke.BRL.MIL> <1523@auspex.auspex.com>
Followup-To: comp.lang.c,comp.lang.fortran
Organization: Purdue University Statistics Department
Lines: 77

In article <1523@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes:
> >Is there anything in pANS C, Fortran 8x, and POSIX that will alleviate this
> >situation?
> 
> No, because:
> 
> 	1) the proposed C 89 standard says little if anything about
> 	   FORTRAN (or is that "Fortran" now?);
> 
> 	2) I suspect the Fortran 8x standard will say little if anything
> 	   about C;
> 
> 	3) the C 89 standard and probably the Fortran 8x standard will
> 	   probably say very little indeed about calling sequences, or
> 	   other compiler-dependent and machine-dependent implementation
> 	   details;
> 
> 	4) POSIX doesn't say anything about them either.
> 
> >It's very annoying, especially these days when all of the really
> >high quality numerical stuff is still in FORTRAN and all of the good user
> >interface stuff is in C.
> 
> This is a "quality of implementation" issue, and was left to the
> marketplace; avoid the "there oughta be a law" syndrome.


There are two problems.  Each implementation of a language will have its
calling sequence.  This problem is unavoidable, and can be a major headache.
About the only thing that can be done about this is to

	a) have the various calling sequences in the #include files, or
	   otherwise, so that any language can call in any of the sequences,

	   and in addition,

	b) have system subroutines which can translate between calling
	   sequences.

This can even be a problem with ONE language.  Programs in Fortran
compiled with one calling sequence on the CDC 6x00 could not call programs
written in the other with arguments, and so there was a problem with the use
of library routines.  Neither was ever implemented, and the machines have
been phased out.



The bigger problem is names.  This seems to have started recently.  In the
systems I have used before UNIX, the statement

	SUBROUTINE ABC(X,Y,Z)

caused an object program with entry point ABC to be produced.  Now, a C
statement

abc(x,y,z)

would produce a program with entry point _abc on most implementations.  I
have seen the Fortran statement above produce one of

ABC, abc, _abc_, _ABC_,

and probably more occur.  These name alterations not only occur in the 
presentation of the name to the system, but in the names of all subroutines
called, blocks used, and global variables.  I have not seen an object code
editor which can modify the files so that this problem can be handled.
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.  A C program cannot now call abc, and a Fortran program
from a processor which prepends and postpends _ cannot call the C program
presented to C as pdq.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)