[Pkg-octave-devel] fw: gfortran transition release goal proposal
George N. White III
gnwiii at gmail.com
Sat Jul 28 14:52:06 UTC 2007
On 7/27/07, Kevin B. McCarty <kmccarty at princeton.edu> 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 <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
More information about the Pkg-octave-devel
mailing list