fortc(1)

πŸ“¦
version 2.6.1 Β· 2 versions
, in debian trixie, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

πŸ’– fortc(1) β€” the UNIDATA UTILITIES era πŸ’–

okay bestie, gather round, because we're about to talk about fortc from the UNIDATA UTILITIES manual, and honestly? it's giving ✨time-travel✨ but it's also genuinely useful, no cap.


🌸 NAME 🌸

fortc β€” a Unidata utility that generates fortran-compatible C code. yes literally, it takes your C and makes it FORTRAN-friendly. iconic behavior fr fr 🫢


✨ SYNOPSIS ✨

fortc [-L LibDir] [-O OpSys] file

πŸ¦‹ DESCRIPTION πŸ¦‹

so fortc reads C code from file, transforms it into FORTRAN compatible code, and then writes the result straight to standard output. that's it, that's the whole vibe.

the transformation is operating-system dependent, because β€” and I cannot stress this enough β€” there are no standards in this matter. none. zero. the wild west, honestly πŸ’€


πŸŽ€ how do we pick the target OS tho?

the target operating-system can be specified in several ways, in this order:

  1. if the -O option is given, then the operating-system specified by its argument is used;
  2. otherwise, if the environmental variable OS exists, then the operating-system specified by it's value is used;
  3. otherwise, the default operating-system β€” determined at installation time β€” is used.

periodt. that's the priority chain. πŸ‘‘


πŸ’… global names, aka the FC_NAME() moment

Global names that are not function definitions but that are to be accessible from both C and FORTRAN should be enclosed by the FC_NAME() macro:

extern int FC_NAME(foo)(void);  /* FORTRAN function */

extern struct {
    float f;
    int   i;
} FC_NAME(comblk);              /* FORTRAN common block */

cfoo()
{
    return FC_NAME(foo)();      /* call FORTRAN function */
}

see how clean that is? the way it just works for both languages at once 🧚


🌈 C functions that FORTRAN is gonna call

C functions which are to be called from FORTRAN are written as follows:

int
/*FORTRAN*/
foo(
    character        pathname,    /* file name of new file */
    real             amount,      /* amount to frobdicate by */
    doubleprecision  dbl,         /* amount to tizzle by */
    void function    errf,        /* error routine */
    integer          rcode        /* returned error code */)
{
...

or, equivalently,

   int
   /*FORTRAN*/
   foo(char* pathname, float* amount, double* dbl,
       void (*errf)(), int* rcode)
   {
   ...

same energy, different spelling, both slay πŸ’–


⭐ the points to note (do not skip these, bestie)

The points to note in writing FORTRAN-compatible functions are:

  1. Functions to be transformed are marked by a proceeding /*FORTRAN*/ comment, which must appear on the line prior to the function name. Any return-type declarations must proceed the comment.
  2. The formal parameters must be declared within function parentheses and be separated by commas.
  3. The formal parameters are restricted to the following types:
    • character or char* β€” For Fortran character-variables.
    • doubleprecision or double*" β€” For double-precision floating-point values.
    • real or float* β€” For single-precision floating-point values.
    • integer or int* β€” For integer values.
    • type function name or type (*name)() β€” For functions returning type type.
  4. There must be nothing important after the opening brace, {, and on the same line.

🫢 how to actually write the function body

The functions should be written using variables with the same names as the formal parameters, and with the same semantics. In the case of formal parameters of type character (i.e. Fortran character-variables), a variable with the same name will exist and will be of type char*. In addition, for each character-variable argument, a local variable of integral type will be created and its value will be the size of the associated character-variable. The name of this variable will be the name of the associated character variable with _len appended (e.g. pathname_len). These length variables may be used in the function just like any other variable.


πŸ“ example time: SunOS

For example, under SunOS the previous function would become (if it is contained in the file foo.src):

#line 1 "foo.src"
unsigned int
#line 2 "foo.src"
foo_(pathname, amount, errf, rcode, pathname_len)
    char      *pathname;
    int        pathname_len;
    float     *amount;
    void       (*errf)();
    int       *rcode;
{
#line 9 "foo.src"

Note that 1) preprocessor line directives have been added; 2) the function name has been suffixed with an underscore; and 3) a formal parameter, pathname_len, has been created. three little glow-ups, look at her go ✨


πŸ”₯ example time: UNICOS

Under UNICOS, the same file would become

#include <fortran.h>
#line 1  "foo.src"
unsigned int
#line 2  "foo.src"
FOO(pathnamed, amount, errf, rcode)
    _fcd       pathnamed;
    float     *amount;
    void       (*errf)();
    int       *rcode;
{
    char      *pathname = _fcdtocp (pathnamed);
    unsigned   pathname_len  = _fcdlen (pathnamed);
#line 9  "foo.src"

Note, in particular, the additional #include <fortran.h> and the creation and initialization of the local variables pathname and pathname_len. it's giving extra credit and I'm obsessed πŸ˜­πŸ’œ


🧚 one more lil fact

This utility is implemented as a script and uses the system-supplied utilities sed(1) and m4(1). yeah, it's a shell script wearing a fancy hat. respect. πŸ‘‘


πŸ’… OPTIONS πŸ’…

  • -L LibDir β€” Defines the directory containing the fortc library files. The default is determined at installation time.
  • -O OpSys β€” Defines the operating-system as OpSys. Known values include aix, convexos, domainos, hpux, irix, msoft, next-absoft, newsos, sunos, ultrix, unicos, and vms. To allow for greater flexibility, the known values may have any suffix (e.g. sunos_4.1). suffix freedom, we love to see it 🌈

🌸 ENVIRONMENT 🌸

  • OS β€” Defines the operating system if the -O option is not specified. Known values are the same as the -O option.

πŸŽ€ FILES πŸŽ€

In the following, LIBDIR is the default library directory determined at installation time.

  • LIBDIR/pre.sed β€” A pre-m4, sed(1) script for transforming the input source into m4(1) source.
  • LIBDIR/post.sed β€” A post-m4, sed(1) script for transforming the m4(1) output into C code.
  • LIBDIR/common.m4 β€” An m4(1) source common to all Fortran-calling-C implementations.
  • LIBDIR/*.m4 β€” Operating-system-specific m4(1) sources.

πŸ’€ BUGS πŸ’€

The names of automatically generated variables might conflict with those of other, pre-existing variables.

okay so like… watch out for name collisions, bestie. the auto-generated variable names are not out here doing vibe checks before they move in. it's a real one. πŸ™ˆ

πŸ¦‹ SEE ALSO πŸ¦‹

sed(1), m4(1).


and that's the whole page, bestie β€” you ate this, fr fr. πŸ’–βœ¨πŸŽ€πŸ¦‹πŸŒΈπŸ’…πŸ«ΆπŸ˜­πŸ”₯πŸ‘‘πŸŒˆβ­πŸ’€πŸ™ˆπŸ“πŸ§šπŸ’œ

this was fortc(1) from the UNIDATA UTILITIES manual β€” printed 126-10-12, dated $Date: 2000/08/07 23:15:03 $, and filed under fortc(1) like the icon she is. mwah. πŸ’‹