example/factorial for an example of this use case.
WARNING: node-ffi assumes you know what you're doing. You can pretty easily create situations where you will segfault the interpreter and unless you've got C debugger skills, you probably won't know what's going on.
var ffi = ;var libm = "libm" "ceil": "double" "double" ;libm; // 2// You can also access just functions in the current process by passing a nullvar current = null "atoi": "int32" "string" ;current; // 1234
libfficomes bundled with node-ffi, it does not need to be installed on your system.
0.4branch of node-ffi.
$ npm install node-ffi
Most popular operating systems have a pre-compiled binary that comes along with node-ffi, so most of the time you will not need to compile anything! (Unless of course you want to, then see below).
To compile from source it's easiest to use
$ npm install -g node-gyp
Now you can compile
$ git clone git://github.com/rbranson/node-ffi.git$ cd node-ffi$ node-gyp configure build
int8 Signed 8-bit Integer uint8 Unsigned 8-bit Integer int16 Signed 16-bit Integer uint16 Unsigned 16-bit Integer int32 Signed 32-bit Integer uint32 Unsigned 32-bit Integer int64 Signed 64-bit Integer uint64 Unsigned 64-bit Integer float Single Precision Floating Point Number (float) double Double Precision Floating Point Number (double) pointer Pointer Type string Null-Terminated String (char *)
In addition to the basic types, there are type aliases for common C types.
byte unsigned char char char uchar unsigned char short short ushort unsigned short int int uint unsigned int long long ulong unsigned long longlong long ulonglong unsigned long long size_t platform-dependent, usually pointer size
Internally, V8 stores integers that will fit into a 32-bit space in a 32-bit integer, and those that fall outside of this get put into double-precision floating point numbers. This is problematic because FP numbers are imprecise. To get around this, the methods in node-ffi that deal with 64-bit integers return strings and can accept strings as parameters.
There is non-trivial overhead associated with FFI calls. Comparing a hard-coded binding version of
strtoul() to an FFI version of
strtoul() shows that the native hard-coded binding is 5x faster. So don't just use the C version of a function just because it's faster. There's a significant cost in FFI calls, so make them worth it.
MIT License. See the