[Pkg-octave-devel] fw: gfortran transition release goal proposal

[George N. White III]

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