Xref: utzoo comp.lang.c:18331 comp.lang.fortran:2003 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). Message-ID: <1278@l.cc.purdue.edu> Date: 3 May 89 19:37:24 GMT References: <2846@tank.uchicago.edu> <5785@cbnews.ATT.COM> <10087@smoke.BRL.MIL> <1544@auspex.auspex.com> Followup-To: comp.lang.c,comp.lang.fortran Organization: Purdue University Statistics Department Lines: 80 In article <1544@auspex.auspex.com>, guy@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@l.cc.purdue.edu (Internet, bitnet, UUCP)