### 7.3 FFTW Fortran type reference ¶

The following are the most important type correspondences between the C interface and Fortran:

- Plans (`fftw_plan` and variants) are `type(C_PTR)` (i.e. an opaque pointer).
- The C floating-point types `double`, `float`, and `long double` correspond to `real(C_DOUBLE)`, `real(C_FLOAT)`, and `real(C_LONG_DOUBLE)`, respectively. The C complex types `fftw_complex`, `fftwf_complex`, and `fftwl_complex` correspond in Fortran to `complex(C_DOUBLE_COMPLEX)`, `complex(C_FLOAT_COMPLEX)`, and `complex(C_LONG_DOUBLE_COMPLEX)`, respectively. Just as in C (see Precision), the FFTW subroutines and types are prefixed with ‘`fftw_`’, `fftwf_`, and `fftwl_` for the different precisions, and link to different libraries (`-lfftw3`, `-lfftw3f`, and `-lfftw3l` on Unix), but use the same include file `fftw3.f03` and the same constants (all of which begin with ‘`FFTW_`’). The exception is `long double` precision, for which you should also include `fftw3l.f03` (see Extended and quadruple precision in Fortran).
- The C integer types `int` and `unsigned` (used for planner flags) become `integer(C_INT)`. The C integer type `ptrdiff_t` (e.g. in the 64-bit Guru Interface) becomes `integer(C_INTPTR_T)`, and `size_t` (in `fftw_malloc` etc.) becomes `integer(C_SIZE_T)`.
- The `fftw_r2r_kind` type (see Real-to-Real Transform Kinds) becomes `integer(C_FFTW_R2R_KIND)`. The various constant values of the C enumerated type (`FFTW_R2HC` etc.) become simply integer constants of the same names in Fortran.
- Numeric array pointer arguments (e.g. `double *`) become `dimension(*), intent(out)` arrays of the same type, or `dimension(*), intent(in)` if they are pointers to constant data (e.g. `const int *`). There are a few exceptions where numeric pointers refer to scalar outputs (e.g. for `fftw_flops`), in which case they are `intent(out)` scalar arguments in Fortran too. For the new-array execute functions (see New-array Execute Functions), the input arrays are declared `dimension(*), intent(inout)`, since they can be modified in the case of in-place or `FFTW_DESTROY_INPUT` transforms.
- Pointer return values (e.g `double *`) become `type(C_PTR)`. (If they are pointers to arrays, as for `fftw_alloc_real`, you can convert them back to Fortran array pointers with the standard intrinsic function `c_f_pointer`.)
- The `fftw_iodim` type in the guru interface (see Guru vector and transform sizes) becomes `type(fftw_iodim)` in Fortran, a derived data type (the Fortran analogue of C’s `struct`) with three `integer(C_INT)` components: `n`, `is`, and `os`, with the same meanings as in C. The `fftw_iodim64` type in the 64-bit guru interface (see 64-bit Guru Interface) is the same, except that its components are of type `integer(C_INTPTR_T)`.
- Using the wisdom import/export functions from Fortran is a bit tricky, and is discussed in Accessing the wisdom API from Fortran. In brief, the `FILE *` arguments map to `type(C_PTR)`, `const char *` to `character(C_CHAR), dimension(*), intent(in)` (null-terminated!), and the generic read-char/write-char functions map to `type(C_FUNPTR)`.

You may be wondering if you need to search-and-replace `real(kind(0.0d0))` (or whatever your favorite Fortran spelling of “double precision” is) with `real(C_DOUBLE)` everywhere in your program, and similarly for `complex` and `integer` types. The answer is no; you can still use your existing types. As long as these types match their C counterparts, things should work without a hitch. The worst that can happen, e.g. in the (unlikely) event of a system where `real(kind(0.0d0))` is different from `real(C_DOUBLE)`, is that the compiler will give you a type-mismatch error. That is, if you don’t use the `iso_c_binding` kinds you need to accept at least the theoretical possibility of having to change your code in response to compiler errors on some future machine, but you don’t need to worry about silently compiling incorrect code that yields runtime errors.