Xref: utzoo comp.lang.c:18353 comp.lang.fortran:2008
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.lang.c,comp.lang.fortran
Subject: Re: Calling FORTRAN from C (Was: Need matrix inversion C routine).
Message-ID: <1557@auspex.auspex.com>
Date: 4 May 89 06:39:12 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: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 71

>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,

Uhh, this tends to involve extensions to the language, as in VMS C's
"%VAL", etc. (or whatever the syntax is).  If you have a C routine that
expects an integral value, and you want to call it from a Fortran
routine, "considerable work with complicated data structures" ain't
going to cut it.

>but presumably these matters are problems of the language and not of
>the implementation.

The "value vs. reference" is a problem of the language. However, the
"Fortran character strings vs. C character strings" problem, which is a
*separate* part of this problem (it has nothing to do with value vs.
reference), is a matter of the implementation - C strings'
implementation tends to be constrained by the language definition
(although there could conceivably be surprises, if the implementor works
hard enough :-)), but Fortran strings' implementation aren't necessarily
so constrained.

For example, a quick check of the 4.3BSD F77 libraries indicate that its
"f77" (and, I suspect, most other UNIX "f77" implementations, since many
of them are derived from Feldman's) passes a Fortran string type by
passing a pointer to a character array (well, to its first element)
followed by an integral string length.  Said character arrays can be
blank-padded at the end (I think this may be
language-definition-related).

This is *not* what a typical C routine expects to see as a string.  I
don't know that there is a way in "standard Fortran" to pass a string in
a way that a naive C routine would find acceptable, and that will work
on all Fortran and C implementations (if somebody thinks there is, they
should exhibit it in detail, otherwise I'm not inclined to believe
them).  You could add an extension to Fortran to pass "C-style strings",
but not all Fortrans will necessarily support this; you'd have to get it
added to the language.

However, once you've done that, you now have questions like "how do I
pass a standard I/O stream pointer to a C routine that expects it?" 
Standard Fortran doesn't have structures, much less an "address of"
operator, so passing a standard I/O stream pointer - defined in most
UNIX standard I/O implementations, at least, as a pointer to a
particular type of data structure - is a bit hard....

Given the problems listed here, the "best approach" is probably to have
the C routines you call from Fortran be set up to have
"Fortran-generatable" calling sequences; this may mean you have to have
"jacket" routines for popular C routines with non-Fortran-generatable
calling sequences.  This may mean, though, that the "jacket" routine may
depend on the particular calling conventions of the Fortran you're
using; for instance, consider a Fortran that passes strings by passing
a pointer to the characters and the length vs. a Fortran that passes
them by passing a pointer to a block of memory containing the length
followed by the characters.

Of course, moving back to the structure problem, even if your Fortran
*does* support structures (I think VMS C and other ones have that as an
extension), there's no guarantee from the language specs that they'll
lay out data structures in the same way....

In short, your presumption is incorrect; it *is* an implementation problem.

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

If one is speaking of names in C, why should one want to "name a main
program"?  What could you do given that facility that you can't do
without it?