Foreign function interface

FFIs exist to bridge the gap between languages with different type systems, memory models, and calling conventions. They allow a high-level language like Python or Java to call C functions, which is crucial for performance-critical tasks or for accessing operating system APIs. The design of an FFI typically involves a foreign function declaration, which specifies the name, parameters, and return type of the external routine, and a runtime mechanism that marshals arguments and results across the boundary.

Marshalling is a key challenge: data structures must be converted between representations, and memory management must be coordinated to avoid leaks or corruption. Some FFIs, like the Java Native Interface (JNI), provide a rich set of functions for creating and manipulating Java objects from native code, while others, like Python's ctypes, allow direct calls to C functions with minimal overhead.

Many languages provide built-in FFI support. For example, Python's ctypes and cffi allow calling C libraries, while Ruby's Fiddle and Perl's XS serve similar purposes. In the .NET world, P/Invoke (Platform Invoke) enables C# to call native Windows APIs. For languages that run on a virtual machine, such as Java and Go, FFIs often rely on the C ABI as the lingua franca.

Libraries like libffi provide a portable way to call functions at runtime without compile-time knowledge of their signatures. This is used by many interpreters and JIT compilers to implement dynamic FFIs. The Foreign Function Interface (FFI) is also a key feature of systems languages like Rust, where the extern keyword and #[link] attribute allow safe interop with C libraries.

FFIs introduce several risks, including type mismatches, memory safety violations, and platform-specific behavior. A common issue is the difference in calling conventions (e.g., cdecl vs. stdcall on x86), which can cause crashes if not handled correctly. To mitigate these, many FFIs require explicit annotations or use wrapper libraries that perform checks.

In safe languages like Rust, FFI calls are marked unsafe, forcing the programmer to acknowledge the risk. Tools like bindgen automatically generate Rust bindings from C headers, reducing manual errors. For higher-level languages, FFIs can be a source of security vulnerabilities if untrusted data is passed without validation, as seen in buffer overflow exploits.

Beyond the mainstream use cases, FFIs have niche applications. For instance, the libffi library is used by the GNU Compiler Collection (GCC) to implement closures and callbacks in languages like Go and Haskell. The JNR-FFI (Java Native Runtime) provides an alternative to JNI with better performance and no need for generated headers.

Historically, the concept of FFIs predates modern languages: early PL/I and COBOL systems had mechanisms to call routines written in other languages, often using the operating system's linkage conventions. In the 1980s, the Common Lisp community developed the UFFI (Universal Foreign Function Interface) to unify various Lisp implementations. More recently, WebAssembly's wasm-ffi allows calling JavaScript functions from WebAssembly modules, enabling high-performance web applications.

Marshalling

The process of converting data structures between different representations, often used in FFIs to pass arguments and return values across language boundaries.

Calling convention

A set of rules that dictate how function calls are made at the machine level, including how arguments are passed and who cleans up the stack.

C ABI

The Application Binary Interface for the C programming language, which serves as a common standard for inter-language calls.

JNI

Java Native Interface, a framework that allows Java code to call native applications and libraries written in C, C++, or assembly.

libffi

A library that provides a portable high-level interface to various calling conventions, allowing a program to call functions at runtime.