Pb mixing C & Fortran IO

[craig@jcb-sc.com]

>craig@jcb-sc.com wrote:
>
>> > I encounter a problem when mixing C and Fortran IO in my code. Here are samples that
>> > reproduce the problem :
>>
>> Don't do that.  Any file or unit opened in one module cannot be safely
>> accessed in another module (via the usual language facilities, anyway,
>> which includes g77's libU77 routines, such as FGETC) *unless* that module
>> is uses the same level of language facilities (where Fortran's WRITE and
>> g77's FPUTC are on *two* different levels) *and* is compiled by the same
>> compiler.
>
>Do you mean C's FPUTC ?

No, but they (C's fputc and libU77's FPUTC) do amount to the same thing,
and thus should actually be usable interchangeably, even to the same
file/unit.

>I do understand but this is working on most of the systems I am using and Linux (+egcs)
>(which is quite important for me) is the only one which crashes.
>I was thinking that by the end the fortran library was in C so I was expecting the mix  to
>work at least for stdout...;-(

Perhaps if you investigated the crash yourself, you would find out what's
not working and learn how to work around it.  E.g. maybe what is happening
is that libI77 (the part of libg2c/libf2c that handles the actual run-time
I/O for things like OPEN, PRINT, READ, WRITE, etc.) thinks the unit is
not yet open, and does an (implicit) OPEN on it to start writing, but it
*has* already been written to in C, leading to a crash.

Thing is, we just don't *promise* that this sort of mixing will work, and
we do need to make that lack of promise more clear in the docs.  But
that doesn't mean you won't be able to get it to work in your particular
case -- to do that, though, you might have to do some of the "heavy
lifting" (debugging, etc.) yourself.

By the way, are you saying this combination works on other systems,
using the exact same versions of gcc and g77?  If that's the case,
it suggests the difference is in the C library on the Linux system
you're using -- perhaps it's more sensitive to incorrect usage of it
by application code (which includes libg2c at this level) than the
other systems.

>> One approach I think some people use to avoid this whole problem is to
>> code all I/O in C, and all number-crunching in Fortran, when they have
>> to use both.
>
>This is indeed a good idea but my code is running out-of-core and I would do the same
>if I could get in C the same performance as for the fortran direct unformatted I/O... but
>anyway if there is no other alternative.

I'm not sure what "out-of-core" means here.  And, surely, you *can* get
the same performance for *any* I/O out of C that you can out of Fortran,
especially when using gcc and g77, since you can always write the C library
calls directly in C instead of g77 having to call libg2c, an intermediate
level.  But you'd have to research a bit to get it right (assuming
compatibility with g77-written direct unformatted files is important).

What I'm saying here is that, of the kinds of code where g77 might beat
gcc, I/O is *not* included in those kinds as far as I know -- only certain
kinds of number-crunching code.

        tq vm, (burley)