From: pa@curly.appmag.com (Pierre Asselin)
Newsgroups: comp.unix.aix
Subject: Re: C/fortran interface
Date: 28 Sep 92 16:32:07 GMT
	<MARKE.92Sep26104420@fsi-ssd.csg.ssd.fsi.com>
Distribution: na
Organization: Applied Magnetics, Goleta, CA

In <MARKE.92Sep26104420@fsi-ssd.csg.ssd.fsi.com>
	marke@fsi-ssd.csg.ssd.fsi.com (Mark W. Easter) writes:

>Bunk!  This is not uncommon and every major UNIX FORTRAN and C
>compiler (I do not include intel related junk here, sorry) does
>document the interlanguage interface (XLC does a marvelous job!).

Oh?  In a C routine, how do I write to a file that was OPENed by Fortran?
Oops.  You were right.  InfoExplorer does have something to say.

  Input/Output:

    To improve performance, the XL FORTRAN run-time library has
    its own buffers and its own handling of these buffers.  XL
    FORTRAN routines and routines of other languages should not
    perform input/output on the same data files within the same
    executable program.  However, if such mixing of
    input/output is required, the data file should be opened
    and explicitly closed within XL FORTRAN routines before any
    input/output operations are performed on that file by
    routines written in another language.  If any XL FORTRAN
    routines contain WRITE statements, and these routines are
    used in an executable program in which the main program is
    not written in XL FORTRAN, you must explicitly  CLOSE the
    data file in an XL FORTRAN routine to ensure that the
    buffers are flushed.

In other words, you can't do it.  IF you are writing new code and if
you MUST mix I/O, the WORKAROUND is to repeatedly close and reopen the
file with append intent.  Note that both sides must know a path to the
file.  Now suppose you are porting mixed code from a hypothetical
platform that had fully integrated I/O.  Do you like spaghetti?

This is not a complaint about IBM, incidentally.  At least they
document the fact that I/O internals are not documented.

>There are many reasons C and FORTRAN get mixed not least of which is
>the fact that there is a LOT of FORTRAN code out there (and FORTRAN
>fluent engineers) which must continue to be leveraged in the real
>world.  I don't like it, but then I don't always like being bound by
>gravity either.

Fortunately much of the Fortran-code-out-there crunches numbers from
memory to memory.  It is *fairly safe* to mix such code with C.  But I
stick to my guiding principle:  the more intimately you mix system
operations between the C and Fortran portions, the more exquisite your
nightmares will be when you move to a different machine --or OS
release!

>As for the original problem, he is obviously ignoring the fact that
>FORTRAN stores data column-major while C stores it row-major.

Maybe.  Li said that some of the data were printed in reverse order.
It sounds more like a case of buffer jumble than matrix transposition.

DISCLAIMER:  I'm still at 2006.  The specifics may have changed in
3.2.x  --which would only make my case stronger.

(We have a moratorium on upgrades until our new site adminstrator
starts next week.  It's a lot of fun reading the "PTF hell" thread
with a free mind :-)
-- 

--Pierre Asselin, Magnetoresistive Head Engineering, Applied Magnetics.
  pa@appmag.com        the usual disclaimers apply.