Hello

I am using a data file which is opened in FORTRAN and the same file
goes inside the C code for writing. I send the file unit in the
fortran part and the same needs to be mapped to the File stream on
entering in to C so that i can continue working with the same file. I
wonder if this conversion is possible.
My scenario looks like this....
void fprint_message(int fileUnit)
{
/* conversion from fileUnit to File *f should happen here*/

call cprint_message(File *f);
}
Here i call fprint_message from Fortran and before this the file is
opened. Kindly help me out if any of you have ideas on this.

Arun

<abarun22> wrote:

> I am using a data file which is opened in FORTRAN and the same file
> goes inside the C code for writing. I send the file unit in the
> fortran part and the same needs to be mapped to the File stream on
> entering in to C so that i can continue working with the same file. I
> wonder if this conversion is possible.

It is possible with some compilers, but it is *HIGHLY* system dependent.
This kind of capability is explicitly excluded from even the f2003 C
interop features.

While it can sometimes work, there are all kinds of subtleties that can
cause problems. One of the more "obvious" ones is that the Fortran
runtimes might buffer data in such a way that trying to intermix C and
Fortran I/O can cause data to get on the file in the "wrong" order.

I highly recommend that you do the I/O to each file with only one
language. You can use different languages for different files. Actually,
you can do it for the same file if you close the file on one language
before opening it in the other, which can be a major bother.

What I recommend is that, if the file is opened in Fortran, you can
provide a small Fortran wrapper procedure to write to the file and then
call this Fortran procedure from any C code that needs it. Or
conversely, if the file is opened in C, provide a small C wrapper
function to write to the file and call that from any Fortran code that
needs it. Choose one of those two options.

Although I repeat my recommendation against it, ff you feel that you
really need to intermix the I/O in a compiler-dependent way, then people
would need to know what compiler you were using. I've seen things for
that on some compilers, but it is compiler dependent. I'm afraid I don't
off-hand know the details for any particular compiler, as I follow my
own advice on this one. But others here might know. Be aware that it
might not be possible at all on some compilers.

>Although I repeat my recommendation against it, ff you feel that you
>really need to intermix the I/O in a compiler-dependent way, then people
>would need to know what compiler you were using.

Strongly seconded. Although I've made code with I/O to the same
file in both C and Fortran work, I do NOT recommend going this route.
It is WAY too system dependent and minor changes to build environment
can cause it to break.

Consider this to be a "waltzing bear" thing. The wonder is not how
well the bear waltzes, the wonder is that the bear waltzes at all.

FInally, if you decide to go ahead with that foolishness anyway,
you will need to be very explicit about the compilers used, and
dev environment and target.

On May 12, 11:13 am, abaru...@gmail.com wrote:
> Hello
>
> I am using a data file which is opened in FORTRAN and the same file
> goes inside the C code for writing. I send the file unit in the
> fortran part and the same needs to be mapped to the File stream on
> entering in to C so that i can continue working with the same file. I
> wonder if this conversion is possible.
> My scenario looks like this....
> void fprint_message(int fileUnit)
> {
> /* conversion from fileUnit to File *f should happen here*/
>
> call cprint_message(File *f);}
>
> Here i call fprint_message from Fortran and before this the file is
> opened. Kindly help me out if any of you have ideas on this.


Yes, don't do it that way!

You can pass a "string" containing formatted text between languages
instead. In C you have sprintf. In Fortran you have internal write.
It's far easier to figure out how to pass a string between languages.
Even so, you need to provide details of compiler, operating system,
etc.

-- elliot

I am using Hp compiler in Unix, PGI compiler in Linux 32b & 64b and
compaq visual fortran for Win32. I too not in favor of mixingup
languages for I/O operation. Because of some project related
constraints i have to do like this.

abarun22 wrote:
[..]

On 14 mei, 11:56, abaru...@gmail.com wrote:
> I am using Hp compiler in Unix, PGI compiler in Linux 32b & 64b and
> compaq visual fortran for Win32. I too not in favor of mixingup
> languages for I/O operation. Because of some project related
> constraints i have to do like this.
>>
> abaru...@gmail.com wrote:
>>
>
> - Tekst uit oorspronkelijk bericht weergeven -

Your best bet is still to delegate all I/O to a (small) set of
subroutines/functions
written in one language. Especially since you mention three completely
different compilers and platforms, it will be a gargantuan task to use
the
mixture you asked for. That way you can focus on the much simpler
task of creating a mixed-language program. There is more than enough
expertise in this newsgroup to help with that.

Regards,

Arjen

>I am using Hp compiler in Unix, PGI compiler in Linux 32b & 64b and
>compaq visual fortran for Win32. I too not in favor of mixingup
>languages for I/O operation. Because of some project related
>constraints i have to do like this.

I don't know much about Unix compilers, when I did this stuff
it was for 16 bit real mode DOS and Win32 console mode targets.
We used MS Fortran PDS 5.1 with MS VC 1.52c for the 16 bit
stuff and for the Win32 stuff we used both MS FPS4 with VC 4
and Watcom F77 & C/C++ both v10.6.

I can tell you that I am pretty sure it canNOT be done with
CVF and any C/C++ compilers for Win32. When the FPS4/VC4
code was migrated to DVF5/VC5 the simultaneous dual-language
I/O to the same file broke badly. It only worked on FPS4/VC4
because MS used the VC4 runtime as the basis for the FPS4 runtime.
When Digital introduced DVF5 as the FPS4 successor, we got a much
better compiler, but two distinct, separate runtimes. The
MS PDS 5.1 w/ VC 1.52c and the Watcom F77 & C/C++ work for the
same reason -- for both the Fortran RTL is built on top of the
C RTL.

TO do this in Unix you would either need a Fortran built on C
and USING THE C RTL AS THE BASIS FOR THE FORTRAN RTL --or--
you will need to get into RTL implementation arcana.
That sounds like G77/GCC or G95/GCC or GFortran/GCC are probably
your best candidates. F2C and any decent C compiler is another
possibility.

For Win32, OpenWatcom is one option, the GNUish toosets mentioned
are another and F2C is your fall-back.

Now, that I've outlined the steps needed, I ask you once again
to reconsider. If you are still sure you wish to pass through
the portal under the "abandon all hope, ye who enter here" then
ask away. I'll try to answer any questions you ask.

abarun22 wrote:

> I am using Hp compiler in Unix, PGI compiler in Linux 32b & 64b and
> compaq visual fortran for Win32. I too not in favor of mixingup
> languages for I/O operation. Because of some project related
> constraints i have to do like this.

When I worked with the HP-UX compiler some years ago, maybe HP-UX
7.0 or so, it was easy to do. The Fortran library used the C library
to do its I/O, and included functions that allowed one to mix them.
I believe one to find the C stream for an open Fortran unit, and
another to connect a Fortran unit to an open stream.

That would likely not be portable to Linux or Win32.

-- glen

In article <1179136560.520819.142220>,
abarun22 wrote:

> I am using Hp compiler in Unix, PGI compiler in Linux 32b & 64b and
> compaq visual fortran for Win32. I too not in favor of mixingup
> languages for I/O operation. Because of some project related
> constraints i have to do like this.

I think at least the HP compiler supports the POSIX interface
routines. These allow fortran to do I/O through C file descriptors.
If the other compilers also support POSIX, then that is probably the
easiest and most portable way to achieve what you want with a
minimum of wheel reinvention.

$.02 -Ron Shepard

On May 12, 8:13 am, abaru...@gmail.com wrote:
> Hello
>
> I am using a data file which is opened in FORTRAN and the same file
> goes inside the C code for writing. I send the file unit in the
> fortran part and the same needs to be mapped to the File stream on
> entering in to C so that i can continue working with the same file. I
> wonder if this conversion is possible.
> My scenario looks like this....
> void fprint_message(int fileUnit)
> {
> /* conversion from fileUnit to File *f should happen here*/
>
> call cprint_message(File *f);}
>
> Here i call fprint_message from Fortran and before this the file is
> opened. Kindly help me out if any of you have ideas on this.

Check if your Fortran implementation supports the function getfilep.

Bob Corbett

e p chandler wrote:

> On May 12, 11:13 am, abaru...@gmail.com wrote:
>> Yes, don't do it that way!
>
> You can pass a "string" containing formatted text between languages
> instead. In C you have sprintf. In Fortran you have internal write.
> It's far easier to figure out how to pass a string between languages.
> Even so, you need to provide details of compiler, operating system,
> etc.
>
> -- elliot

That's good advice, but following it is not so so easy, either.

Fortran strings have (until the recent ISO varying string addendum was
created) been fixed length (padded to full length with blanks if needed), C
strings are of variable length terminated by a null character. String
arguments are passed differently by Fortran and C compilers; Fortran
compilers usually pass the address of the beginning string and the string
length as an additional hidden parameter, either immediately after the
string address or at the end of the parameter list.

Some Fortran compilers allow BIND(C) attributes for subroutines and similar
attributes for arguments.

You will need to read the inter-language-operation sections of your Fortran
and C compiler documentation to get this to work properly.

-- mecej4

On Tue, 15 May 2007 09:44:06 -0500, Ron Shepard
<ron-shepard> wrote:

> In article <1179136560.520819.142220>,
> abarun22 wrote:
>
> > I am using Hp compiler in Unix, PGI compiler in Linux 32b & 64b and
> > compaq visual fortran for Win32. I too not in favor of mixingup
> > languages for I/O operation. Because of some project related
> > constraints i have to do like this.
>
> I think at least the HP compiler supports the POSIX interface
> routines. These allow fortran to do I/O through C file descriptors.

File descriptors aren't C; they are Unix/POSIX, and are _usable_ from
C just as they are usable from Fortran with the binding. C's own
buffered formatted I/O uses 'FILE *' pointers. But:

> If the other compilers also support POSIX, then that is probably the
> easiest and most portable way to achieve what you want with a
> minimum of wheel reinvention.
>
Yes, if all support POSIX, that would be a common denominator.

- formerly david.thompson1 || achar(64) || worldnet.att.net

David Thompson wrote:
(snip)

>>I think at least the HP compiler supports the POSIX interface
>>routines. These allow fortran to do I/O through C file descriptors.

> File descriptors aren't C; they are Unix/POSIX, and are _usable_ from
> C just as they are usable from Fortran with the binding. C's own
> buffered formatted I/O uses 'FILE *' pointers. But:

I did manage once to use popen() from Fortran under HP-UX 7.0.
I believe using popen(), then finding the file descriptor
that was used, then dup2() to associate that with the file
descriptor that Fortran used. HP-UX Fortran supplies a routine
to find the file descriptor.

File descriptors are unix, but often used in unix C code.

-- glen

glen herrmannsfeldt wrote:
>
> David Thompson wrote:
> (snip)
>>
> I did manage once to use popen() from Fortran under HP-UX 7.0.
> I believe using popen(), then finding the file descriptor
> that was used, then dup2() to associate that with the file
> descriptor that Fortran used. HP-UX Fortran supplies a routine
> to find the file descriptor.
>
> File descriptors are unix, but often used in unix C code.

As Ron mentioned, compilers which support the POSIX PXF routines allow
discovery and usage of file descriptors. For example, the PXFFILENO
routine obtains the POSIX file descriptor associated with a particular
Fortran unit. The PXFFDOPEN routine is another handy routine
which allows a caller to open a Fortran unit on a particular POSIX file
descriptor.

Sure Would Be Nice if the g95 and/or gfortran folks would implement PXF
in their libraries...

However PXF does not define interoperation with the C stdio package.

W.