Xref: utzoo comp.lang.c:18346 comp.lang.fortran:2007 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!cmcl2!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.lang.c,comp.lang.fortran Subject: Re: Calling FORTRAN from C Message-ID: <10201@smoke.BRL.MIL> Date: 4 May 89 04:10:56 GMT References: <2846@tank.uchicago.edu> <5785@cbnews.ATT.COM> <10087@smoke.BRL.MIL> <1544@auspex.auspex.com> <1278@l.cc.purdue.edu> Reply-To: gwyn@brl.arpa (Doug Gwyn) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 43 In article <1278@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >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. Woo, woo, let's also insist on a LISP compatible interface. Let's also make C set up the run-time I/O support, activation contexts, garbage collection, etc. needed by other languages just in case we use them.. >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. I don't suppose you ever named any of your functions Q8Q...? Name clashes among external identifiers has been a practical problem ever since the invention of the link editor. UNIX had several constraints that caused the external name mapping conventions that it had. One of them was a pre-existing assembler that had no way to prevent names such as "r0" the register from being confused with "r0" the external datum. This caused the C compiler to give external identifiers an unmistakable form. When preexisting assembly code was not an issue, as with the 3B series, the opposite approach of giving registers etc. unique name formats such as "%0" was followed and external identifiers were left alone. C and Fortran external identifiers could not be mixed (such as in implementing Fortran run-time support in C), due to differences in behavior expected for the same names. For example, SUBROUTINE FOPEN. >Speaking of names, why should one not be able to name a main program? Why add unnecessary complexity?