0
+ − 1 \name{dyncall}
+ − 2 \alias{.dyncall}
+ − 3 \alias{dyncall}
+ − 4 \alias{.dyncall.default}
+ − 5 \alias{.dyncall.cdecl}
+ − 6 \alias{.dyncall.stdcall}
+ − 7 \alias{.dyncall.thiscall}
+ − 8 \alias{.dyncall.thiscall.msvc}
+ − 9 \alias{.dyncall.thiscall.gcc}
+ − 10 \alias{.dyncall.fastcall.msvc}
+ − 11 \alias{.dyncall.fastcall.gcc}
+ − 12 \alias{signature}
+ − 13 \alias{call signature}
+ − 14 \alias{type signature}
+ − 15 \title{Foreign Function Interface with support for almost all C types}
+ − 16 \description{
+ − 17 Functions to call pre-compiled code with support for most C argument and return types.
+ − 18 }
+ − 19 \usage{
+ − 20 .dyncall( address, signature, ... , callmode = "default" )
+ − 21 .dyncall.default ( address, signature, ... )
+ − 22 .dyncall.cdecl ( address, signature, ... )
+ − 23 .dyncall.stdcall ( address, signature, ... )
+ − 24 .dyncall.thiscall ( address, signature, ... )
+ − 25 .dyncall.thiscall.msvc( address, signature, ... )
+ − 26 .dyncall.thiscall.gcc ( address, signature, ... )
+ − 27 .dyncall.fastcall.msvc( address, signature, ... )
+ − 28 .dyncall.fastcall.gcc ( address, signature, ... )
+ − 29 }
+ − 30 \arguments{
+ − 31 \item{address}{external pointer to foreign function.}
+ − 32 \item{signature}{character string specifying the \emph{call signature} that describes the foreign function type. See details.}
+ − 33 \item{callmode}{character string specifying the \emph{calling convention}. This argument has no effect on most platforms, but on Microsoft Windows 32-Bit Intel/x86 platforms. See details.}
+ − 34 \item{...}{arguments to be passed to the foreign function. Arguments are converted from R to C values according to the \emph{call signature}. See details.}
+ − 35 }
+ − 36 \details{
+ − 37 \code{.dyncall} offers a flexible Foreign Function Interface (FFI) for
+ − 38 the C language with support for calls to arbitrary pre-compiled
+ − 39 C function types at run-time. Almost all C fundamental
+ − 40 argument- and return types are supported including extended support for
+ − 41 pointers. No limitations is given for arity as well.
+ − 42 In addition, on the Microsoft Windows 32-Bit Intel/x86 platform, it supports multiple calling conventions to
+ − 43 interoperate with System DLLs.
+ − 44 Foreign C function types are specified via plain text \emph{type signatures}.
+ − 45 The foreign C function type of the target function is known to the FFI
+ − 46 in advance, before preparation of the foreign call via plain text
+ − 47 \emph{type signature} information.
+ − 48 This has several advantages: R arguments do not need to match exactly.
+ − 49 Although R lacks some fundamental C value types, they are supported via
+ − 50 coercion at this interface (e.g. C \code{float} and 64-bit integer).
+ − 51 Arity and argument type checks help make this interface type-safe
+ − 52 to a certain degree and encourage end-users to use interface from
+ − 53 the interpreter prompt for rapid application development.
+ − 54
+ − 55 The foreign function to be called is specified by \code{address}, which is an external pointer that is obtained from \code{\link{.dynsym}} or \code{\link{getNativeSymbolInfo}}.
+ − 56
+ − 57 \code{signature} is a character string that specifies the formal argument-and-return types of the
+ − 58 foreign function using a \emph{call signature} string. It should match the function type of the foreign function given by \code{address},
+ − 59 otherwise this can lead to a \strong{fatal R process crash}.
+ − 60
+ − 61 The calling convention is specified \emph{explicitly} via function \code{.dyncall}
+ − 62 using the \code{callmode} argument or \emph{implicitly} by using \code{.dyncall.*}
+ − 63 functions. See details below.
+ − 64
+ − 65 Arguments passed via \code{...} are converted to C according to \code{signature} ; see below for details.
+ − 66
+ − 67 Given that the \code{signature} matches the foreign function type, the FFI provides a certain level of type-safety to users, when
+ − 68 exposing foreign functions via call wrappers such as done in \code{\link{dynbind}} and \code{\link{dynport}}.
+ − 69 Several basic argument type-safety checks are done during preparation of the foreign function call:
+ − 70 The arity of formals and actual arguments must match and they must be compatible as well.
+ − 71 Otherwise, the foreign function call is aborted with an error before risking a fatal system crash.
+ − 72 }
+ − 73 \value{
+ − 74 Functions return the received C return value converted to an R value. See section \sQuote{Call Signature} below for details.
+ − 75 }
+ − 76 \section{Type Signature}{
+ − 77 Type signatures are used by almost all other signature formats (call, library, structure and union signature) and also by the low-level (un)-\code{\link{packing}} functions.
+ − 78
+ − 79 The following table gives a list of valid type signatures for all supported C types.
+ − 80
+ − 81 \tabular{clll}{
+ − 82 \strong{Type Signature} \tab \strong{C type} \tab \strong{valid R argument types} \tab \strong{R return type}\cr
+ − 83 '\code{B}' \tab bool \tab raw,logical,integer,double \tab logical\cr
+ − 84 '\code{c}' \tab char \tab raw,logical,integer,double \tab integer\cr
+ − 85 '\code{C}' \tab unsigned char \tab raw,logical,integer,double \tab integer\cr
+ − 86 '\code{s}' \tab short \tab raw,logical,integer,double \tab integer\cr
+ − 87 '\code{S}' \tab unsigned short \tab raw,logical,integer,double \tab integer\cr
+ − 88 '\code{i}' \tab int \tab raw,logical,integer,double \tab integer\cr
+ − 89 '\code{I}' \tab unsigned int \tab raw,logical,integer,double \tab double\cr
+ − 90 '\code{j}' \tab long \tab raw,logical,integer,double \tab double\cr
+ − 91 '\code{J}' \tab unsigned long \tab raw,logical,integer,double \tab double\cr
+ − 92 '\code{l}' \tab long long \tab raw,logical,integer,double \tab double\cr
+ − 93 '\code{L}' \tab unsigned long long \tab raw,logical,integer,double \tab double\cr
+ − 94 '\code{f}' \tab float \tab raw,logical,integer,double \tab double\cr
+ − 95 '\code{d}' \tab double \tab raw,logical,integer,double \tab double\cr
+ − 96 '\code{p}' \tab \emph{C pointer} \tab \emph{any vector},externalptr,NULL \tab externalptr\cr
+ − 97 '\code{Z}' \tab char* \tab character,NULL \tab character or NULL\cr
+ − 98 '\code{x}' \tab SEXP \tab \emph{any} \tab \emph{any}\cr
+ − 99 '\code{v}' \tab void \tab \emph{invalid} \tab NULL\cr
+ − 100 '\code{*}' \ldots \tab \emph{C type}* (pointer) \tab \emph{any vector},externalptr,NULL \tab externalptr\cr
+ − 101 "\code{*<}" \emph{typename} '\code{>}' \tab \emph{typename}* (pointer) \tab raw,externalptr \tab externalptr\cr
+ − 102 }
+ − 103
+ − 104 The last two rows of the table the above refer to \emph{typed pointer} signatures.
+ − 105 If they appear as a return type signature, the external pointer returned is
+ − 106 a S3 \code{struct} object. See \code{\link{new.struct}} for details.
+ − 107
+ − 108 }
+ − 109 \section{Call Signatures}{
+ − 110 Call Signatures are used by \code{\link{.dyncall}} and \code{\link{new.callback}} to describe foreign C function types.
+ − 111 The general form of a call signature is as following:
+ − 112
+ − 113 \tabular{lll}{
+ − 114 (\emph{argument-type})* \tab \code{')'} \tab \emph{return-type} \cr
+ − 115 }
+ − 116
+ − 117 The calling sequence given by the \bold{argument types signature} is specified in direct \emph{left-to-right} order of the formal argument types defined in C.
+ − 118 The type signatures are put in sequence without any white space in between.
+ − 119 A closing bracket character '\code{)}' marks the end of argument types, followed by a
+ − 120 single \bold{return type signature}.
+ − 121
+ − 122 Derived pointer types can be specified as untyped pointers via \code{'p'}
+ − 123 or via prefix \code{'*'} following the underlying base type (e.g. \code{'*d'} for \code{double *})
+ − 124 which is more type-safe. For example, this can prevent users from passing a \code{numeric} R atomic as \code{int*} if using \code{'*i'} instead of \code{'p'}.
+ − 125
+ − 126 Dervied pointer types to aggregate \code{union} or \code{struct} types are
+ − 127 supported in combination with the framework for handling foreign data types.
+ − 128 See \code{\link{new.struct}} for details. Once a C type is registered,
+ − 129 the signature \code{*<}\emph{typename}\code{>} can be used to refer to a pointer to an aggregate C object \emph{type}\code{*}.
+ − 130 If typed pointers to aggregate objects are used as a return type and the corresponding type information exists, the returned value can be printed and accessed symbolically.
+ − 131
+ − 132 Here are some examples of C function prototypes and corresponding call signatures:
+ − 133
+ − 134 \tabular{rll}{
+ − 135 \tab \emph{C Function Prototype} \tab \emph{Call Signature} \cr
+ − 136 \code{double} \tab \code{sqrt(double);} \tab \code{"d)d"} \cr
+ − 137 \code{double} \tab \code{dnorm(double,double,double,int);} \tab \code{"dddi)d"} \cr
+ − 138 \code{void} \tab \code{R_isort(int*,int);} \tab \code{"pi)v"} or \code{"*ii)v"} \cr
+ − 139 \code{void} \tab \code{revsort(double*,int*,int);} \tab \code{"ppi)v"} or \code{"*d*ii)v"}\cr
+ − 140 \code{int} \tab \code{SDL_PollEvents(SDL_Event *);} \tab \code{"p)i"} or \code{"*<SDL_Event>)i"} \cr
+ − 141 \code{SDL_Surface*} \tab \code{SDL_SetVideoMode(int,int,int,int);} \tab \code{"iiii)p"} or \code{"iiii)*<SDL_Surface>"} \cr
+ − 142 }
+ − 143
+ − 144 }
+ − 145
+ − 146 \section{Calling convention}{
+ − 147 Calling Conventions specify \sQuote{how} sub-routine calls are performed, and, \sQuote{how} arguments and results are passed,
+ − 148 on machine-level. They differ significantly among families of CPU Architectures
+ − 149 as well as OS and Compiler implementations.
+ − 150
+ − 151 On most platforms, a single \code{"default"} C Calling Convention is used.
+ − 152 As an exception, on the Microsoft Windows 32-Bit Intel/x86 platform several calling conventions are common.
+ − 153 Most of the C libraries still use a \code{"default"} C ( also known as \code{"cdecl"} )
+ − 154 calling convention, but when working with Microsoft System APIs and DLLs, the \code{"stdcall"}
+ − 155 calling convention must be used.
+ − 156
+ − 157 It follows a description of supported Win32 Calling Conventions:
+ − 158
+ − 159 \describe{
+ − 160 \item{\code{"cdecl"}}{Dummy alias to \emph{default}}
+ − 161 \item{\code{"stdcall"}}{C functions with \emph{stdcall} calling convention. Useful for all Microsoft Windows System Libraries (e.g. KERNEL32.DLL, USER32.DLL, OPENGL32.DLL ...). Third-party libraries usually prefer the default C \emph{cdecl} calling convention. }
+ − 162 \item{\code{"fastcall.msvc"}}{C functions with \emph{fastcall} calling convention compiled with Microsoft Visual C++ Compiler. Very rare usage.}
+ − 163 \item{\code{"fastcall.gcc"}}{C functions with \emph{fastcall} calling convention compiled with GNU C Compiler. Very rare usage.}
+ − 164 \item{\code{"thiscall"}}{C++ member functions.}
+ − 165 \item{\code{"thiscall.gcc"}}{C++ member functions compiled with GNU C Compiler.}
+ − 166 \item{\code{"thiscall.msvc"}}{C++ member functions compiled with Microsoft Visual C++ Compiler.}
+ − 167 }
+ − 168
+ − 169 As of the current version of this package and for practical reasons, the \code{callmode} argument does not have an effect on almost
+ − 170 all platforms, except that if R is running on Microsoft Windows 32-Bit Intel/x86 platform, \code{.dyncall} uses the specified calling convention.
+ − 171 For example, when loading OpenGL across platforms, \code{"stdcall"} should be used instead of \code{"default"},
+ − 172 because on Windows, OpenGL is a System DLL. This is very exceptional, as in most other cases, \code{"default"} (or \code{"cdecl"}, the alias) need to be used
+ − 173 for normal C shared libraries on Windows.
+ − 174
+ − 175 At this stage of development, support for C++ calls should be considered experimental.
+ − 176 Support for Fortran is planed but not yet implemented in dyncall.
+ − 177 }
+ − 178 \section{Portability}{
+ − 179 The implementation is based on the \emph{dyncall} library (part of the DynCall project).
+ − 180
+ − 181 The following processor architectures are supported: X86 32- and 64-bit, ARM v4t-v7 oabi/eabi (aapcs) and armhf including support for Thumb ISA, PowerPC 32-bit, MIPS 32- and 64-Bit, SPARC 32- and 64-bit; The library
+ − 182 has been built and tested to work on various OSs: Linux, Mac OS X, Windows 32/64-bit, BSDs, Haiku, Nexenta/Open Solaris, Solaris, Minix and Plan9,
+ − 183 as well as embedded platforms such as Linux/ARM (OpenMoko, Beagleboard, Gumstix, Efika MX, Raspberry Pi), Nintendo DS (ARM), Sony Playstation Portable (MIPS 32-bit/eabi) and iOS (ARM - armv6 mode ok, armv7 unstable).
+ − 184 In the context of R, dyncall has currently no support for PowerPC 64-Bit.
+ − 185 }
+ − 186 \note{
+ − 187 The target address, calling convention and call signature \strong{MUST} match foreign function type, otherwise the invocation could lead to a \strong{fatal R process crash}.
+ − 188 }
+ − 189 \examples{
+ − 190 \donttest{
+ − 191 mathlib <- dynfind(c("msvcrt","m","m.so.6"))
+ − 192 x <- .dynsym(mathlib,"sqrt")
+ − 193 .dyncall(x, "d)d", 144L)
+ − 194 }
+ − 195 }
+ − 196 \references{
+ − 197 Adler, D. (2012) \dQuote{Foreign Library Interface}, \emph{The R Journal}, \bold{4(1)}, 30--40, June 2012.
+ − 198 \url{http://journal.r-project.org/archive/2012-1/RJournal_2012-1_Adler.pdf}
+ − 199
+ − 200 Adler, D., Philipp, T. (2008) \emph{DynCall Project}.
+ − 201 \url{http://dyncall.org}
+ − 202 }
+ − 203 \seealso{
+ − 204 \code{\link{.dynsym}} and \code{\link[base]{getNativeSymbolInfo}} for resolving symbols,
+ − 205 \code{\link{dynbind}} for binding several foreign functions via thin call wrappers,
+ − 206 \code{\link[base]{.C}} for the traditional FFI to C.
+ − 207 }
+ − 208 \keyword{programming}
+ − 209 \keyword{interface}