joe@hanauma.Stanford.EDU (Joe Dellinger) (09/20/90)
Our basic research software consists of mostly Fortran "main" programs linked in with libraries mostly written in C. We use the C libraries exclusively to do all I/O. This has worked fine on many different UNIX systems for years. We just got the latest OS upgrade, which is the first one to be "POSIX-compliant". Now we are told "if you want to be able to use C I/O you'll have to have your mains in C"! This means rewriting a LOT of software. OK. Are we really a special case? Is there anybody else out there that writes Fortran mains but uses C to do the I/O? If so, let me know, so we can make a case to them not to do this! \ /\ /\ /\/\/\/\/\/\/\.-.-.-.-.......___________ \ / \ / \ /Dept of Geophysics, Stanford University \/\/\.-.-....___ \/ \/ \/Joe Dellinger joe@hanauma.stanford.edu apple!hanauma!joe\/\.-._ ************** Reading News again, when I should be writing my thesis... *******
silvert@cs.dal.ca (Bill Silvert) (09/21/90)
In article <1044@helens.Stanford.EDU> joe@hanauma.Stanford.EDU (Joe Dellinger) writes: > >We just got the latest OS upgrade, which is the first one to be >"POSIX-compliant". Now we are told "if you want to be able to use C I/O >you'll have to have your mains in C"! This means rewriting a LOT of software. > > OK. Are we really a special case? Is there anybody else out there >that writes Fortran mains but uses C to do the I/O? If so, let me know, so >we can make a case to them not to do this! This would be an absolute disaster. We use C I/O extensively for things like graphics, raw input, and to do things like display a file directory when asking the user to input a data file name. If true, someone had better come up with a fix awfully fast! -- William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2. Tel. (902)426-1577 UUCP=..!{uunet|watmath}!dalcs!biomel!bill BITNET=bill%biomel%dalcs@dalac InterNet=bill%biomel@cs.dal.ca
staff@cadlab.sublink.ORG (Alex Martelli) (09/21/90)
joe@hanauma.Stanford.EDU (Joe Dellinger) writes: ... > OK. Are we really a special case? Is there anybody else out there >that writes Fortran mains but uses C to do the I/O? If so, let me know, so >we can make a case to them not to do this! We also use a lot of C routines for I/O within a mostly-fortran framework! Particularly because this can speed up I/O from 50% to 2000% (NOT a misprint - 20 times!) on Unix, OS/2, and Apollo; apparently the Fortran I/O model mismatches these machines and/or is too general for efficiency, while with C we can special-case optimize what we really need, and FLY. You have my full support!!! -- Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 45, Bologna, Italia Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; Fax: ++39 (51) 366964 (work only; any time of day or night).
mike@DRD.Com (Mike Rovak) (09/21/90)
bill%biomel@cs.dal.ca wrote: } In article <1044@helens.Stanford.EDU> joe@hanauma.Stanford.EDU (Joe Dellinger) writes: } > } >We just got the latest OS upgrade, which is the first one to be } >"POSIX-compliant". Now we are told "if you want to be able to use C I/O } >you'll have to have your mains in C"! This means rewriting a LOT of software. } > } > OK. Are we really a special case? Is there anybody else out there } >that writes Fortran mains but uses C to do the I/O? If so, let me know, so } >we can make a case to them not to do this! } } This would be an absolute disaster. We use C I/O extensively for things } like graphics, raw input, and to do things like display a file directory } when asking the user to input a data file name. If true, someone had } better come up with a fix awfully fast! Not a problem, guys. Make a C main function whose sole purpose is to call the Fortran routine. Change the word "PROGRAM" in each Fortran routine to "SUBROUTINE" and your job is done. -- Mike ------------------------------------------------------------------------ Disclaimer: My opinions do not necessarily reflect those of my employer. ======================================================================== ------------------------------------------------------------------------ mike@DRD.Com uunet!apctrc!drd!mike ========================================================================
flint@gistdev.gist.com (Flint Pellett) (09/23/90)
mike@DRD.Com (Mike Rovak) writes: >bill%biomel@cs.dal.ca wrote: >} In article <1044@helens.Stanford.EDU> joe@hanauma.Stanford.EDU (Joe Dellinger) writes: >} > >} >We just got the latest OS upgrade, which is the first one to be >} >"POSIX-compliant". Now we are told "if you want to be able to use C I/O >} >you'll have to have your mains in C"! This means rewriting a LOT of software. >} > >} > OK. Are we really a special case? Is there anybody else out there >} >that writes Fortran mains but uses C to do the I/O? If so, let me know, so >} >we can make a case to them not to do this! No. We have an app here which used C for all I/O from a main body in FORTRAN for a long time, since it ran about twice as fast using C I/O as it did using whatever it is that FORTRAN uses. However, it now lives with a C main, a FORTRAN middle, and C I/O, because it is ever so much nicer to get command line options with getopt() than to try to manhandle them in FORTRAN. >} This would be an absolute disaster. We use C I/O extensively for things >} like graphics, raw input, and to do things like display a file directory >} when asking the user to input a data file name. If true, someone had >} better come up with a fix awfully fast! >Not a problem, guys. Make a C main function whose sole purpose is to call >the Fortran routine. Change the word "PROGRAM" in each Fortran routine >to "SUBROUTINE" and your job is done. My guess is that you've never done it on a "real" program. If your FORTRAN main is messing around getting command line parameters in, you're going to have more to do than just this: handing the null-terminated C argv[] strings down to the FORTRAN part that expects space-filled strings is not especially difficult, but it isn't a 1 minute fix either. -- Flint Pellett, Global Information Systems Technology, Inc. 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 uunet!gistdev!flint or flint@gistdev.gist.com
jerry@violet.berkeley.edu (Jerry Berkman) (09/23/90)
In article <1990Sep21.132232.11305@DRD.Com> mike@DRD.Com (Mike Rovak) writes: >bill%biomel@cs.dal.ca wrote: > In article <1044@helens.Stanford.EDU> joe@hanauma.Stanford.EDU (Joe Dellinger) writes: > > > >... Now we are told "if you want to be able to use C I/O > >you'll have to have your mains in C"! This means rewriting a LOT of software. > > >Not a problem, guys. Make a C main function whose sole purpose is to call >the Fortran routine. Change the word "PROGRAM" in each Fortran routine >to "SUBROUTINE" and your job is done. >-- Mike There's also the question of whether you want to run in the C environment or the Fortran environment. If you want to do I/O in Fortran, you may need to call the Fortran environment initialization routine; it's called "f_init()" in BSD VAX UNIX. It initializes units 0, 5, and 6 to standard error, standard input and standard output and line-buffers standard error. It also sets up to catch interrupts so that all your Fortran file buffers are flushed on error termination, and so that you get semi-inteligent messages. - Jerry Berkman, U.C.Berkeley, (415)642-4804 jerry@violet.berkeley.edu disclaimer: opinions are my own, not my employers, etc.
khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) (09/24/90)
>apparently the Fortran I/O model mismatches these machines and/or
Unix f77 I/O is often bad performance wise, but this is due to
history, not technical inevitability.
Converting a fortran main to a C main to ensure the right I/O
environment usually is not that hard. Just cobble up a virtually empty
C main which calls Fmain (which is your real program, written in
fortran).
I would hazard to guess that with appropriate library/loader munging
you might be able to avoid this slight of hand. Personally, I prefer
to modify the source code for maxiumum portability ... but I recognize
that it may be easier/more expiedient to alter the environment.
--
----------------------------------------------------------------
Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043hirchert@harriett.ncsa.uiuc.edu (Kurt Hirchert) (10/01/90)
In article <1990Sep21.132232.11305@DRD.Com> mike@DRD.Com (Mike Rovak) writes: >bill%biomel@cs.dal.ca wrote: >} This would be an absolute disaster. We use C I/O extensively for things >} like graphics, raw input, and to do things like display a file directory >} when asking the user to input a data file name. If true, someone had >} better come up with a fix awfully fast! > >Not a problem, guys. Make a C main function whose sole purpose is to call >the Fortran routine. Change the word "PROGRAM" in each Fortran routine >to "SUBROUTINE" and your job is done. This "solution" works only if you are willing to give up using Fortran I/O. There are a number of people who want to be able to use _both_ Fortran I/O and C I/O. (In the future, similar issues may apply to error handling and memory management.) -- Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
thorson@typhoon.atmos.colostate.edu (Bill Thorson) (10/02/90)
In article <1990Oct1.155217.24452@ux1.cso.uiuc.edu> hirchert@harriett.ncsa.uiuc.edu (Kurt Hirchert) writes: >In article <1990Sep21.132232.11305@DRD.Com> mike@DRD.Com (Mike Rovak) writes: > >This "solution" works only if you are willing to give up using Fortran I/O. >There are a number of people who want to be able to use _both_ Fortran I/O >and C I/O. (In the future, similar issues may apply to error handling and >memory management.) >-- >Kurt W. Hirchert hirchert@ncsa.uiuc.edu >National Center for Supercomputing Applications On our Sun we have built in C calls named f_init() and f_exit() to alow FORTRAN io. I'm not sure about all Sun compilers but I have used it and it seems to work alright. Bill Thorson #!/bin/sh #-----------------------------------------------------------------------# echo Bill Thorson thorson@typhoon.atmos.colostate.edu echo Dept of Atmospheric Science +1 303 491-8339 echo Colorado State University echo Ft. Collins, CO 80523 Cray||Sun||Amiga -- I can't decide? #-----------------------------------------------------------------------#
mike@DRD.Com (Mike Rovak) (10/02/90)
hirchert@harriett.ncsa.uiuc.edu (Kurt Hirchert) wrote: } In article <1990Sep21.132232.11305@DRD.Com> mike@DRD.Com (Mike Rovak) writes: } >bill%biomel@cs.dal.ca wrote: } >} This would be an absolute disaster. We use C I/O extensively for things } >} like graphics, raw input, and to do things like display a file directory } >} when asking the user to input a data file name. If true, someone had } >} better come up with a fix awfully fast! } > } >Not a problem, guys. Make a C main function whose sole purpose is to call } >the Fortran routine. Change the word "PROGRAM" in each Fortran routine } >to "SUBROUTINE" and your job is done. } } This "solution" works only if you are willing to give up using Fortran I/O. } There are a number of people who want to be able to use _both_ Fortran I/O } and C I/O. (In the future, similar issues may apply to error handling and } memory management.) We have a suite of applications which uses a C main function and which allows both C and Fortran I/O. The two platforms we run this application on are (forgive me) MSDOS PC's, and a SUN (I'm so insulated from it I don't even know what it is - I think it's a SPARC). Since my experience in mixed languages is limited to these two platforms, I assumed that other platforms would also allow this to occur. This is why my original posting was so full of enthusiasm. I stand corrected. ------------------------------------------------------------------------ Disclaimer: My opinions do not necessarily reflect those of my employer. ======================================================================== ------------------------------------------------------------------------ mike@DRD.Com uunet!apctrc!drd!mike ========================================================================
shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) (10/02/90)
No one here has mentioned just why or how the POSIX standard mandates that C IO can't be used with a Fortran main. How/why does this limitation arise in POSIX? -P. ************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************** Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY 10027 (212)854-1418 shenkin@cunixc.cc.columbia.edu(Internet) shenkin@cunixc(Bitnet) ***"In scenic New York... where the third world is only a subway ride away."***
patrick@convex.COM (Patrick F. McGehearty) (10/02/90)
In article <1990Oct2.124559.19410@cunixf.cc.columbia.edu> shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) writes: >No one here has mentioned just why or how the POSIX standard mandates that > C IO can't be used with a Fortran main. > >How/why does this limitation arise in POSIX? -------- The problem with C I/O in a Fortran main apparently was an implementation problem for some vendor's version of POSIX. It is certainly not a requirement of POSIX. Convex offers POSIX, ANSI C, and allows C I/O with a Fortran main. Speaking as user/customer rather than a vendor, I would complain to my vendor if C I/O used to work with a Fortran main and it stopped due to a POSIX upgrade. I would expect most vendors to fix this sort of problem in the next release if not sooner. Speaking for myself, Patrick McGehearty
karl@haddock.ima.isc.com (Karl Heuer) (10/03/90)
In article <1990Oct2.124559.19410@cunixf.cc.columbia.edu> shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) writes: >No one here has mentioned just why or how the POSIX standard mandates that C >IO can't be used with a Fortran main. > >How/why does this limitation arise in POSIX? POSIX does not mandate any such thing. The situation is just that one particular vendor, in the process of providing POSIX support, no longer allows that particular mixed-language kludge. The problem is that there is some initialization that needs to be done before the program starts. Evidently this is done by the C linkage but not by Fortran. If the vendor is committed to supporting the language-mixing you need, then they ought to be able to put the appropriate hooks into the Fortran startup as well. Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint