cfortran.html

Cfortran is useful for mixing language programing when you want call some C function in your FORTRAN

defined by default in <tt>cfortran.h</tt>. 
[The Sun and HP compilers have not been
tested, so they may also require <tt>LOGICAL_STRICT</tt> as the default.]

<p></p></li><li> <tt>SHORT</tt> and <tt>BYTE</tt>
<p> 
  They are irrelevant for the CRAY where <i>FORTRAN</i> 
has no equivalent to C's <tt>short</tt>.
Similarly <tt>BYTE</tt> is irrelevant for <tt>f2c</tt> and for VAX Ultrix <tt>f77</tt> and fort. The
author has tested SHORT and BYTE with a modified cfortest.c/cfortex.f on all
machines supported except for the HP9000 and the Sun.
</p><p>
  <tt>BYTE</tt> is a signed 8-bit quantity, i.e. values are -128 to 127, 
on all machines
except for the SGI [at least for MIPS Computer Systems 2.0.] On the SGI it is
an unsigned 8-bit quantity, i.e. values are 0 to 255, although the SGI '<i>FORTRAN</i>
77 Programmers Guide' claims BYTE is signed. Perhaps MIPS 2.0 is dated, since
the DECstations using MIPS 2.10 <tt>f77</tt> have a signed <tt>BYTE</tt>.
</p><p>
  To minimize the difficulties of signed and unsigned 
<tt>BYTE</tt>, <tt>cfortran.h</tt> creates
the type '<tt>INTEGER_BYTE</tt>' to agree with <i>FORTRAN</i>'s 
<tt>BYTE</tt>. Users may define 
<tt>SIGNED_BYTE</tt> or 
<tt>UNSIGNED_BYTE</tt>, before including <tt>cfortran.h</tt>, 
to specify <i>FORTRAN</i>'s
<tt>BYTE</tt>. If neither is defined, <tt>cfortran.h</tt> assumes 
<tt>SIGNED_BYTE</tt>.

</p><p></p></li><li> CRAY
<p>
  The type <tt>DOUBLE</tt> in <tt>cfortran.h</tt> 
  corresponds to <i>FORTRAN</i>'s <tt>DOUBLE PRECISION</tt>.
  The type <tt>FLOAT</tt> in <tt>cfortran.h</tt> corresponds to 
  <i>FORTRAN</i>'s <tt>REAL</tt>.
</p><p>
On a classic CRAY [i.e. all models except for the t3e]:
<font color="#993300"><pre>( 64 bit) C float       == C double == <i>FORTRAN</i> REAL
(128 bit) C long double             == <i>FORTRAN</i> DOUBLE PRECISION
</pre></font>
Therefore when moving a mixed C and <i>FORTRAN</i> app. to/from a classic CRAY,
either the C code will have to change,
or the <i>FORTRAN</i> code and <tt>cfortran.h</tt> declarations will have to 
change.
<tt>DOUBLE_PRECISION</tt> is a <tt>cfortran.h</tt> macro which provides the former option,
i.e. the C code is automatically changed.
<tt>DOUBLE_PRECISION</tt> is 'long double' on classic CRAY and 'double' elsewhere.
<tt>DOUBLE_PRECISION</tt> thus corresponds to <i>FORTRAN</i>'s <tt>DOUBLE PRECISION</tt>
on all machines, including classic CRAY.
</p><p>
On a classic CRAY with the <i>FORTRAN</i> compiler flag <tt>'-dp'</tt>:
<i>FORTRAN</i> <tt>DOUBLE PRECISION</tt> thus is also the faster 64bit type.
(This switch is often used since the application is usually satisfied by
 64 bit precision and the application needs the speed.)
<tt>DOUBLE_PRECISION</tt> is thus not required in this case,
since the classic CRAY behaves like all other machines.
If <tt>DOUBLE_PRECISION</tt> is used nonetheless, then on the classic CRAY
the default <tt>cfortran.h</tt> behavior must be overridden,
for example by the C compiler option <tt>'-DDOUBLE_PRECISION=double'</tt>.
</p><p>
On a CRAY t3e:
<font color="#993300"><pre>(32 bit) C float                   == <i>FORTRAN</i> Unavailable
(64 bit) C double == C long double == <i>FORTRAN</i> REAL == <i>FORTRAN</i> DOUBLE PRECISION
</pre></font>
Notes:
</p><ul>
<p></p><li> (32 bit) is available as <i>FORTRAN</i> <tt>REAL*4</tt> and
  (64 bit) is available as <i>FORTRAN</i> <tt>REAL*8</tt>.
  Since <tt>cfortran.h</tt> is all about more portability, not about less portability,
  the use of the nonstandard <tt>REAL*4</tt> and <tt>REAL*8</tt> is strongly discouraged.
<p></p></li><li> <i>FORTRAN</i> <tt>DOUBLE PRECISION</tt> is folded to <tt>REAL</tt> with 
   the following warning:
<font color="#993300"><pre>    DOUBLE PRECISION is not supported on this platform.  REAL will be used.
</pre></font>
  Similarly, <i>FORTRAN</i> <tt>REAL*16</tt> is mapped to <tt>REAL*8</tt> with a warning.
This behavior differs from that of other machines, including the classic CRAY.
<tt>FORTRAN_REAL</tt> is thus introduced for the t3e,
just as <tt>DOUBLE_PRECISION</tt> is introduced for the classic CRAY.
<tt>FORTRAN_REAL</tt> is '<tt>double</tt>' on t3e and '<tt>float</tt>' elsewhere.
<tt>FORTRAN_REAL</tt> thus corresponds to <i>FORTRAN</i>'s <tt>REAL</tt> 
on all machines, including t3e.
</li></ul>

<p></p></li><li> <tt>f2c</tt>
<p>
  <tt>f2c</tt>, by default promotes <tt>REAL</tt> functions to double. 
<tt>cfortran.h</tt> does not (yet)
support this, so the <tt>f2c -R</tt> option must be used to turn this promotion off.

</p><p></p></li><li> <tt>f2c</tt>
<p>[Thanks to Dario Autiero for pointing out the following.]
<tt>f2c</tt> has a strange feature in that either one or two underscores are appended
to a <i>FORTRAN</i> name of a routine or common block,
depending on whether or not the original name contains an underscore.
<b><pre>   S.I. Feldman et al., "A <i>FORTRAN</i> to C converter",
   Computing Science Technical Report No. 149.

   page 2, chapter 2: INTERLANGUAGE conventions
   ...........
</pre></b>
   To avoid conflict with the names of library routines and with names that
   <tt>f2c</tt> generates,
   <i>FORTRAN</i> names may have one or two underscores appended. 
   <i>FORTRAN</i> names are
   forced to lower case (unless the -U option described in Appendix B is in
   effect); external names, i.e. the names of <i>FORTRAN</i> procedures 
   and common
   blocks, have a single underscore appended if they do not contain any
   underscore and have a pair of underscores appended if they do contain
   underscores. Thus <i>FORTRAN</i> subroutines names <tt>ABC</tt>, 
   <tt>A_B_C</tt> and <tt>A_B_C_</tt> result
   in C functions named <tt>abc</tt>_, <tt>a_b_c__</tt> and <tt>a_b_c___</tt>.
</p><p>

<tt>cfortran.h</tt> is unable to change the naming convention on a name by name basis.
<i>FORTRAN</i> routine and common block names which do not contain an underscore
are unaffected by this feature.
Names which do contain an underscore may use the following work-around:

<font color="#993300"><pre>/* First 2 lines are a completely standard <tt>cfortran.h</tt> interface
   to the <i>FORTRAN</i> routine E_ASY . */
                  PROTOCCALLSFSUB2(E_ASY,e_asy, PINT, INT)
#define E_ASY(A,B)     CCALLSFSUB2(E_ASY,e_asy, PINT, INT, A, B)
#ifdef f2cFortran
#define e_asy_ e_asy__
#endif
/* Last three lines are a work-around for the strange f2c naming feature. */
</pre></font>

</p><p></p></li><li> NAG f90
<p>  The <i>FORTRAN</i> 77 subset of <i>FORTRAN</i> 90 is supported. 
Extending <tt>cfortran.h</tt> to 
interface C with all of <i>FORTRAN</i> 90 has not yet been examined.
<br>  The NAG f90 library hij acks the <tt>main()</tt> of any program and starts the user's 
program with a call to: <tt>void f90_main(void)</tt>;<br>
While this in itself is only a minor hassle, a major problem arises because
NAG f90 provides no mechanism to access command line arguments.<br>
  At least version 'NAGWare f90 compiler Version 1.1(334)' appended _CB to
common block names instead of the usual <tt>_</tt>. 
To fix, add this to <tt>cfortran.h</tt>:
<font color="#993300"></font></p><pre><font color="#993300">#ifdef old_NAG_f90_CB_COMMON
#define COMMON_BLOCK                 CFC_  /* for all other Fortran compilers */
#else
#define COMMON_BLOCK(UN,LN)          _(LN,_CB)
#endif
</font></pre>

<p></p></li><li> RS/6000
<p>  Using <tt>"xlf -qextname ..."</tt>, which appends an underscore, <tt>'_'</tt>, 
to all <i>FORTRAN</i>
external references, requires <tt>"cc -Dextname ..."</tt> so that 
<tt>cfortran.h</tt> also
generates these underscores.
Use i<tt>-Dextname=extname</tt> if <tt>extname</tt> is a symbol used in 
the C code.
The use of <tt>"xlf -qextname"</tt> is <b>strongly encouraged</b>, since it 
allows for
transparent naming schemes when mixing C and <i>FORTRAN</i>.

</p><p></p></li><li> <a name="SIIoHP9000">HP9000</a>
<p>  Using <tt>"f77 +ppu ..."</tt>, which appends an underscore, 
<tt>'_'</tt>, to all <i>FORTRAN</i>
external references, requires <tt>"cc -Dextname ..."</tt> so 
that <tt>cfortran.h</tt> also
generates these underscores.
Use <tt>-Dextname=extname</tt> if extname is a symbol used in the C code.
The use of <tt>"f77 +ppu"</tt> is <b>strongly encouraged</b>, since it allows 
for
transparent naming schemes when mixing C and <i>FORTRAN</i>.
</p><p>
  At least one release of the HP <tt>/lib/cpp.ansi</tt>
 preprocessor is broken and will
go into an infinite loop when trying to process <tt>cfortran.h</tt> with the
<tt>##</tt> catenation operator. The K&amp;R version of <tt>cfortran.h</tt> must then be used and the
K&amp;R preprocessor must be specified. e.g.
<font color="#993300"><pre>HP9000&gt; cc -Aa -tp,/lib/cpp -c source.c
</pre></font>
The same problem with a similar solution exists on the Apollo.
An irrelevant error message <tt>'0: extraneous name /usr/include'</tt>
 will appear for
each source file due to another HP bug, and can be safely ignored.
e.g. 
<font color="#993300"><pre>cc -v -c -Aa -tp,/lib/cpp cfortest.c
</pre></font>

 will show that the driver passes
<tt>'-I /usr/include'</tt> instead of <tt>'-I/usr/include'</tt> to 
<tt>/lib/cpp</tt>
</p><p>
On some machines the above error causes compilation to stop; one must then use
K&amp;R C, as with old HP compilers which don't support function prototyping.
<tt>cfortran.h</tt> has to be informed that K&amp;R C is to being used, e.g.
<font color="#993300"><pre>HP9000&gt; cc -D__CF__KnR -c source.c
</pre></font>

</p><p></p></li><li> AbsoftUNIXFortran
<p>
By default, <tt>cfortran.h</tt> follows the default AbsoftUNIX/ProFortran 
and prepends <tt>_C</tt>
to each common block name. To override the <tt>cfortran.h</tt> behavior
<tt>#define COMMON_BLOCK(UN,LN)</tt> before including <tt>cfortran.h</tt>.
[Search for <tt>COMMON_BLOCK</tt> in <tt>cfortran.h</tt> for examples.]

</p><p></p></li><li> <a name="SIIoApollo">Apollo</a>
<p>
On at least one release, 'C compiler 68K Rev6.8(168)', the default C 
preprocessor, from cc -A xansi or cc -A ansi, enters an infinite loop when 
using <tt>cfortran.h</tt>. This Apollo bug can be circumvented by using:
</p><ul>
<p></p><li> <tt>cc -DANSI_C_preprocessor=0</tt> to force use of 
           <tt>/**/</tt>, instead of <tt>'##'</tt>.
<p><b>AND</b> 
</p><p></p></li><li> The pre-ANSI preprocessor, i.e. use <tt>cc -Yp,/usr/lib</tt>
</li></ul>
<p>The same problem with a similar solution exists on the HP.

</p><p></p></li><li> <a name="SIIoSun">Sun</a>
<p>Old versions of cc(1), say &lt;~1986, may require help for <tt>cfortran.h</tt> 
applications:
</p><ul>
 <p></p><li> <tt>#pragma</tt> may not be understood, hence <tt>cfortran.h</tt> 
   and <tt>cfortest.c</tt> may require
<font color="#993300"><pre>sun&gt; mv <tt>cfortran.h</tt> cftmp.h &amp;&amp; grep -v "^#pragma" <cftmp.h>cfortran.h
sun&gt; mv cfortest.c cftmp.c &amp;&amp; grep -v "^#pragma" <cftmp.c>cfortest.c
</cftmp.c></cftmp.h></pre></font>
 <p></p></li><li> Old copies of <tt>math.h</tt> may not include the following from a newer <tt>math.h</tt>.
   [For an ancient <tt>math.h</tt> on a 386 or sparc, get similar from a new <tt>math.h</tt>.]
</li></ul>
<font color="#993300"><pre>   #ifdef mc68000     /* 5 lines Copyright (c) 1988 by Sun Microsystems, Inc. */
   #define FLOATFUNCTIONTYPE	int
   #define RETURNFLOAT(x) 		return (*(int *)(&amp;(x)))
   #define ASSIGNFLOAT(x,y)	*(int *)(&amp;x) = y
   #endif
</pre></font>

<p></p></li><li> CRAY, Sun, Apollo [pre 6.8 cc], VAX Ultrix and HP9000
<p>
  Only <i>FORTRAN</i> routines with less than 15 arguments can be prototyped for C,
since these compilers don't allow more than 31 arguments to a C macro. This can
be overcome, [see Section IV], with access to any C compiler without this
limitation, e.g. gcc, on ANY machine.

</p><p></p></li><li> VAX Ultrix
<p> <tt>vcc (1)</tt> with <tt>f77</tt> is not supported. Although: 
<font color="#993300"><pre>VAXUltrix&gt; f77 -c cfortex.f
VAXUltrix&gt; vcc -o cfortest cfortest.c cfortex.o -lI77 -lU77 -lF77  &amp;&amp;  cfortest
</pre></font>
will link and run. However, the <i>FORTRAN</i> standard I/O is NOT merged 
with the
<tt>stdin</tt> and <tt>stdout</tt> of C, and instead uses the files 
<tt>fort.6</tt> and <tt>fort.5</tt>. For <tt>vcc</tt>,
<tt>f77</tt> can't drive the linking, as for <tt>gcc</tt> and <tt>cc</tt>, 
since <tt>vcc</tt> objects must be
linked using <tt>lk (1)</tt>.  <tt>f77 -v</tt> 
doesn't tell much, and without VAX Ultrix manuals,
the author can only wait for the info. required.
</p><p>
  <tt>fort (1)</tt> is not supported. Without VAX Ultrix manuals the author 
cannot 
convince <tt>vcc/gcc/cc</tt> and <tt>fort</tt> to generate names of 
routines and common blocks
that match at the linker, <tt>lk (1)</tt>. i.e. <tt>vcc/gcc/cc</tt>
 prepend a single underscore
to external references, e.g. <tt>NAME</tt> becomes 
<tt>_NAME</tt>, while fort does not modify the
references. So ... either fort has prepend an underscore to external
references, or <tt>vcc/gcc/cc</tt> have to generate unmodified names. 
<tt>man 1 fort</tt>