The NIF concept was introduced in R13B03 as an EXPERIMENTAL feature. The interfaces may be changed in any way in coming releases. The API is still sparse and contains only the most basic functions to read and write Erlang terms.
R13B04: The function prototypes of the NIFs
have changed to expect
A NIF library contains native implementation of some functions of an erlang module. The native implemented functions (NIFs) are called like any other functions without any difference to the caller. Each NIF must also have an implementation in Erlang that will be invoked if the function is called before the NIF library has been successfully loaded. A typical such stub implementation is to throw an exception. But it can also be used as a fallback implementation if the NIF library is not implemented for some architecture.
A minimal example of a NIF library can look like this:
/* niftest.c */
#include "erl_nif.h"
static ERL_NIF_TERM hello(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[])
{
return enif_make_string(env, "Hello world!");
}
static ErlNifFunc nif_funcs[] =
{
{"hello", 0, hello}
};
ERL_NIF_INIT(niftest,nif_funcs,NULL,NULL,NULL,NULL)
and the erlang module would have to look something like this:
-module(niftest).
-export([init/0, hello/0]).
init() ->
erlang:load_nif("./niftest", 0).
hello() ->
"NIF library not loaded".
and compile and test something like this (on Linux):
$> gcc -fPIC -shared -o niftest.so niftest.c -I $ERL_ROOT/usr/include/
$> erl
1> c(niftest).
{ok,niftest}
2> niftest:hello().
"NIF library not loaded"
3> niftest:init().
ok
4> niftest:hello().
"Hello world!"
A better solution for a real module is to take advantage of
the new directive
A loaded NIF library is tied to the Erlang module code version
that loaded it. If the module is upgraded with a new version, the
new code will have to load its own NIF library (or maybe choose not
to). The new code version can however choose to load the exact
same NIF library as the old code if it wants to. Sharing the same
dynamic library will mean that static data defined by the library
will be shared as well. To avoid unintentionally shared static
data, each Erlang module code can keep its own private data. This
global private data can be set when the NIF library is loaded and
then retrieved by calling
There is currently no way to explicitly unload a NIF
library. A library will be automatically unloaded when the module
code that it belongs to is purged by the code server. A NIF
library will can also be unloaded by replacing it with another
version of the library by a second call to
This is the magic macro to initialize a NIF library. It should be evaluated in global file scope.
The library will fail to load if
Works the same as
The library will fail to load if
Works the same as
The library will fail to load if
typedef struct {
const char* name;
unsigned arity;
ERL_NIF_TERM (*fptr)(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]);
} ErlNifFunc;
Describes a NIF by its name, arity and implementation.
typedef struct {
unsigned size;
unsigned char* data;
} ErlNifBinary;
Variables of type
Allocate memory of
Allocate a new binary of size of
Return an integer less than, equal to, or greater than
zero if
Free memory allocated by
Return the pointer to the private data that was set by
Set
Set
Set
If
Return false if
Set
Initialize the structure pointed to by
Return true if
Return true if
Return true if and only if the two terms are
identical. Corresponds to the Erlang operators
Return true if
Create an atom term from the C-string
Make a badarg exception to be returned from a NIF.
Make a binary term from
Create an floating-point term from a
Try to create the term of an already existing atom from
the C-string
Create an integer term.
Create an ordinary list term of length
Create a list cell
Create a reference like
Create a list containing the characters of the
C-string
Create a tuple term of arity
Create an integer term from an
Release a binary obtained from