Data Type Considerations

Unless otherwise indicated, the function routines listed here are not intrinsics. That means that the type of data a function returns may conflict with the implicit typing of the function name, and require explicit type declaration by the user. For example, getpid() returns INTEGER*4 and would require an INTEGER*4 getpid declaration to ensure proper handling of the result. (Without explicit typing, a REAL result would be assumed by default because the function name starts with g.) As a reminder, explicit type statements appear in the function summaries for these routines.

Be aware that IMPLICIT statements and the -r8, -i2, -dbl and -xtypemap compiler options also alter the data typing of arguments and the treatment of return values. A mismatch between the expected and actual data types in calls to these library routines could cause unexpected behavior. Options -r8 and -dbl promote the data type of INTEGER functions to INTEGER*8, REAL functions to REAL*8, and DOUBLE functions to REAL*16. To protect against these problems, function names and variables appearing in library calls should be explicitly typed with their expected sizes, as in:

    integer*4 seed, getuid
    real*4 ran
    ...
    seed = 70198
    val = getuid() + ran(seed)
    ...

Explicit typing in the example protects the library calls from any data type promotion when the -r8 and -dbl compiler options are used. Without explicit typing, these options could produce unexpected results. See the Fortran User's Guide and the f77(1) and f90(1) man pages for details on these options.

The more flexible -xtypemap compiler option is recommended over the obsolete -i2, -r8, and -dbl options and should be used instead.

You can catch many issues related to type mismatches over library calls by using the Fortran compilers' global program checking option, -Xlist. Global program checking by the f77 and f90 compilers is described in the Fortran User's Guide, the Fortran Programming Guide, and the f77(1) and f90(1) man pages.