base (version 3.1.1)

Foreign: Foreign Function Interface

Description

Functions to make calls to compiled code that has been loaded into R.

Usage

.C(.NAME, ..., NAOK = FALSE, DUP = TRUE, PACKAGE, ENCODING) .Fortran(.NAME, ..., NAOK = FALSE, DUP = TRUE, PACKAGE, ENCODING)

Value

A list similar to the ... list of arguments passed in (including any names given to the arguments), but reflecting any changes made by the C or Fortran code.

Argument types

The mapping of the types of R arguments to C or Fortran arguments is
R C
Fortran integer
int * integer
numeric double *
double precision -- or --
float * real
complex Rcomplex *
double complex logical
int * integer
character char **
[see below] raw
unsigned char * not allowed
list SEXP *
not allowed other
SEXP not allowed
Numeric vectors in R will be passed as type double * to C (and as double precision to Fortran) unless the argument has attribute Csingle set to TRUE (use as.single or single). This mechanism is only intended to be used to facilitate the interfacing of existing C and Fortran code. The C type Rcomplex is defined in ‘Complex.h’ as a typedef struct {double r; double i;}. It may or may not be equivalent to the C99 double complex type, depending on the compiler used. Logical values are sent as 0 (FALSE), 1 (TRUE) or INT_MIN = -2147483648 (NA, but only if NAOK = TRUE), and the compiled code should return one of these three values: however non-zero values other than INT_MIN are mapped to TRUE. Note: The C types corresponding to integer and logical are int, not long as in S. This difference matters on most 64-bit platforms, where int is 32-bit and long is 64-bit (but not on 64-bit Windows). Note: The Fortran type corresponding to logical is integer, not logical: the difference matters on some Fortran compilers. Missing (NA) string values are passed to .C as the string "NA". As the C char type can represent all possible bit patterns there appears to be no way to distinguish missing strings from the string "NA". If this distinction is important use .Call. .Fortran passes the first (only) character string of a character vector is passed as a C character array to Fortran: that may be usable as character*255 if its true length is passed separately. Only up to 255 characters of the string are passed back. (How well this works, and even if it works at all, depends on the C and Fortran compilers and the platform.) Lists, functions are other R objects can (for historical reasons) be passed to .C, but the .Call interface is much preferred. All inputs apart from atomic vectors should be regarded as read-only, and all apart from vectors (including lists), functions and environments are now deprecated.

Warning

DUP = FALSE is dangerous and may be disabled in future versions of R. It was deprecated in R 3.1.0. People concerned about performance and especially memory usage are strongly recommended to use the .Call interface instead of these interfaces. If you pass a local variable to .C/.Fortran with DUP = FALSE, your compiled code can alter the local variable and not just the copy in the return list. Worse, if you pass a local variable that is a formal parameter of the calling function, you may be able to change not only the local variable but the variable one level up. This will be very hard to trace. With DUP = FALSE, character vectors cannot be used, and single precision values will not be returned. It is safe to set DUP = FALSE provided you do not change any of the variables that might be affected, e.g., .C("Cfunction", input = x, output = numeric(10)). In this case the output variable did not exist before the call so is not copied (even with DUP = TRUE). If the input variable is not changed in the C code of Cfunction you would be safe. Unfortunately, there is no automated check that the C function does not change its argument, and authors have frequently done so without realizing it. However, in recent versions of R most unnecessary copying is avoided: on the other hand using DUP = FALSE can omit necessary copying.

Fortran symbol names

All Fortran compilers known to be usable to compile R map symbol names to lower case, and so does .Fortran. Symbol names containing underscores are not valid Fortran 77 (although they are valid in Fortran 9x). Many Fortran 77 compilers will allow them but may translate them in a different way to names not containing underscores. Such names will often work with .Fortran (since how they are translated is detected when R is built and the information used by .Fortran), but portable code should not use Fortran names containing underscores. Use .Fortran with care for compiled Fortran 9x code: it may not work if the Fortran 9x compiler used differs from the Fortran 77 compiler used when configuring R, especially if the subroutine name is not lower-case or includes an underscore. It is also possible to use .C and do any necessary symbol-name translation yourself.

Copying of arguments

If DUP = TRUE there are up to two copies made of each argument in .... Prior to R 2.15.1 there were always two for vectors (one before calling the compiled code and one to collect the results), and this is still the case for character vectors. For other atomic vectors, the argument is not copied before calling the compiled code if it is not otherwise used in the calling code (such as output in the example above). Non-atomic-vector objects are read-only to the C code and are never copied. This behaviour can be changed by setting options(CBoundsCheck = TRUE). In that case raw, logical, integer, double and complex vector arguments are copied both before and after calling the compiled code. The first copy made is extended at each end by guard bytes, and on return it is checked that these are unaltered. For .C, each element of a character vector uses guard bytes.

Details

These functions can be used to make calls to compiled C and Fortran 77 code. Later interfaces are .Call and .External which are more flexible and have better performance.

These functions are primitive, and .NAME is always matched to the first argument supplied (which should not be named). The other named arguments follow ... and so cannot be abbreviated. For clarity, should avoid using names in the arguments passed to ... that match or partially match .NAME.

References

Becker, R. A., Chambers, J. M. and Wilks, A. R. (1988) The New S Language. Wadsworth & Brooks/Cole.

See Also

dyn.load, .Call.

The ‘Writing R Extensions’ manual.