Remember that Fortran and C are different.  For example,

   * Fortran:
	o Passes by reference (address)
	o Routine names are case insensitive
	o Arrays are column-major
	o Strings contain length 

   * C:
	o Passes by value
	o Names are case sensitive
	o Arrays are row-major
	o ``Strings'' are null terminated 

The Fortran support in SLIRP has been tested on a variety of codes, and
even used to publish scientific papers (such as the Kerr Black Black
hole model described in http://arxiv.org/abs/astro-ph/0510688).

The sample code in examples/fortran has been exercised on a number
of compilers, including:

	Linux:		g77, gfortran, Intel Fortran 9.0, Lahey lf95
	Solaris:	f77, f95
	Mac OS/X 10.3:	g77, IBM XL Fortran, Absoft Pro Fortran 9.2

Thanks to Lahey, Intel, IBM, and Absoft for making it easy to use
evaluation copies of their compilers to test this software.

Since version 1.7.7 SLIRP no longer employs f2c to assist with wrapper
generation.  While this may introduce some instability in the near term,
mainly from the fact that SLIRP recognizes a smaller subset of the
Fortran language(s) than does f2c, it was necessary to avoid portability
problems in the generated code.

For example, the legacy f2c semantics for returning complex numbers
TO C scope FROM Fortran functions (an additional argument prepended
to the C function call signature, to accept the return value) are
not employed by modern compilers (such as gfortran in GCC 4.x).
Another portability issue is that the f2c 'complex' typedef shadows
the 'complex' type offered by modern C compilers supporting the ANSI
C99 standard, which can lead to undefined runtime behavior.

Avoiding f2c also makes it easier for SLIRP users to wrap Fortran
codes, since it removes an external dependency (and novice users may
find f2c difficult to build from source), and fosters the automatic
application of OUTPUT annotations to the return values of Fortran
functions.

If the reader is wondering why the venerable (and rather amazing)
cfortran.h was not used here, the answer has several parts:  first,
it did not appear to support gfortran at the time of this writing;
second, as of v2.59 autoconf provides similar Fortran-wrapping
functionality (which SLIRP now employs); third, at 120K it's more
than half the size of the compressed SLIRP tarball, yet much of that
content is for older compilers against which SLIRP will probably never
be used; finally, I suspect using it would've made the generated
code bigger.
