On 7/27/07, Kevin B. McCarty <[EMAIL PROTECTED]> wrote: > George N. White III wrote: > > > This transition should not be a tied to gfortran and the gcc toolchain. > > When > > the code has to change, it should be made to conform to current standards, > > or in a few years we will doing it all over yet again. One approach would > > be > > to adopt the POSX Fortran bindings, the other is to use the current Fortran > > standard. The former has pxf_getarg(), while the latter provides: > > > > call GET_COMMAND_ARGUMENT(iarg, buf, ilen, ierror) > > > > There was an open source implementation of the POSIX fortran bindings > > by Ron Shepard at ANL, and at least one independent implementation has > > been mentioned on c.l.f. > > > > What do you suggest for *C/C++* code that, for whatever reason, needs to > call GETARG() or whatever the modern equivalent is from a FORTRAN library?
This problem can arise using, e.g., a Fortran main program that uses a C/C++ library where the C/C++ needs access to the command-line. You can only count on command-line arguments via the interface available from the Fortran run-time. Since On a POSIX system, every compiler runtime should provide an interface to the command-line arguments (after the normal shell processing). The interface shouldn't mess with the arguments other than copying them into the appropriate string type. In a mixed-language program, routines written in different languages each need their own POSIX bindings. Of course, many codes come from environments that don't provide POSIX-style shell processing, in which case each compiler runtime may give different results, so it may be important to reuse one runtime interface. With such a system you need the ability to call Fortran from C or vice versa, so you should be able to use the -- George N. White III <[EMAIL PROTECTED]> Head of St. Margarets Bay, Nova Scotia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
