# N-API

> Stability: 1 - Experimental

N-API (pronounced N as in the letter, followed by API)

is an API for building native Addons. It is independent from

the underlying JavaScript runtime (ex V8) and is maintained as part of

Node.js itself. This API will be Application Binary Interface (ABI) stable

across versions of Node.js. It is intended to insulate Addons from

changes in the underlying JavaScript engine and allow modules

compiled for one version to run on later versions of Node.js without

recompilation.

Addons are built/packaged with the same approach/tools

The only difference is the set of APIs that are used by the native code.

Instead of using the V8 or [Native Abstractions for Node.js][] APIs,

the functions available in the N-API are used.

APIs exposed by N-API are generally used to create and manipulate

JavaScript values. Concepts and operations generally map to ideas specified

in the ECMA262 Language Specification. The APIs have the following

properties:

- All N-API calls return a status code of type `napi_status`. This

status indicates whether the API call succeeded or failed.

- The API's return value is passed via an out parameter.

- All JavaScript values are abstracted behind an opaque type named

`napi_value`.

- In case of an error status code, additional information can be obtained

using `napi_get_last_error_info`. More information can be found in the error

handling section [Error Handling][].

The documentation for N-API is structured as follows:

* [Basic N-API Data Types][]

* [Error Handling][]

* [Object Lifetime Management][]

* [Module Registration][]

* [Working with JavaScript Values][]

* [Working with JavaScript Values - Abstract Operations][]

* [Working with JavaScript Properties][]

* [Working with JavaScript Functions][]

* [Object Wrap][]

The N-API is a C API that ensures ABI stability across Node.js versions

and different compiler levels. However, we also understand that a C++

API can be easier to use in many cases. To support these cases we expect

there to be one or more C++ wrapper modules that provide an inlineable C++

API. Binaries built with these wrapper modules will depend on the symbols

for the N-API C based functions exported by Node.js. These wrappers are not

part of N-API, nor will they be maintained as part of Node.js. One such

example is: [node-api](https://github.com/nodejs/node-api).

In order to use the N-API functions, include the file

[node_api.h](https://github.com/nodejs/node/blob/master/src/node_api.h)

which is located in the src directory in the node development tree.

For example:

```C

#include <node_api.h>

```

As the feature is experimental it must be enabled with the

following command line

[option](https://nodejs.org/dist/latest-v8.x/docs/api/cli.html#cli_napi_modules):

```bash

--napi-modules

```

## Basic N-API Data Types

N-API exposes the following fundamental datatypes as abstractions that are

consumed by the various APIs. These APIs should be treated as opaque,

introspectable only with other N-API calls.

### *napi_status*

Integral status code indicating the success or failure of a N-API call.

Currently, the following status codes are supported.

```C

typedef enum {

napi_ok,

napi_invalid_arg,

napi_object_expected,

napi_string_expected,

napi_name_expected,

napi_function_expected,

napi_number_expected,

napi_boolean_expected,

napi_array_expected,

napi_generic_failure,

napi_pending_exception,

napi_cancelled,

napi_status_last

} napi_status;

```

If additional information is required upon an API returning a failed status,

it can be obtained by calling `napi_get_last_error_info`.

### *napi_extended_error_info*

```C

typedef struct {

const char* error_message;

void* engine_reserved;

uint32_t engine_error_code;

napi_status error_code;

} napi_extended_error_info;

```

- `error_message`: UTF8-encoded string containing a VM-neutral description of

the error.

- `engine_reserved`: Reserved for VM-specific error details. This is currently

not implemented for any VM.

- `engine_error_code`: VM-specific error code. This is currently

not implemented for any VM.

- `error_code`: The N-API status code that originated with the last error.

See the [Error Handling][] section for additional information.

### *napi_env*

`napi_env` is used to represent a context that the underlying N-API

implementation can use to persist VM-specific state. This structure is passed

to native functions when they're invoked, and it must be passed back when

making N-API calls. Specifically, the same `napi_env` that was passed in when

the initial native function was called must be passed to any subsequent

nested N-API calls. Caching the `napi_env` for the purpose of general reuse is

not allowed.

### *napi_value*

This is an opaque pointer that is used to represent a JavaScript value.

### N-API Memory Management types

#### *napi_handle_scope*

This is an abstraction used to control and modify the lifetime of objects

created within a particular scope. In general, N-API values are created within

the context of a handle scope. When a native method is called from

JavaScript, a default handle scope will exist. If the user does not explicitly

create a new handle scope, N-API values will be created in the default handle

scope. For any invocations of code outside the execution of a native method

(for instance, during a libuv callback invocation), the module is required to

create a scope before invoking any functions that can result in the creation

of JavaScript values.

Handle scopes are created using [`napi_open_handle_scope`][] and are destroyed

using [`napi_close_handle_scope`][]. Closing the scope can indicate to the GC that

all `napi_value`s created during the lifetime of the handle scope are no longer

referenced from the current stack frame.

For more details, review the [Object Lifetime Management][].

#### *napi_escapable_handle_scope*

Escapable handle scopes are a special type of handle scope to return values

created within a particular handle scope to a parent scope.

#### *napi_ref*

This is the abstraction to use to reference a `napi_value`. This allows for

users to manage the lifetimes of JavaScript values, including defining their

minimum lifetimes explicitly.

For more details, review the [Object Lifetime Management][].

### N-API Callback types

#### *napi_callback_info*

Opaque datatype that is passed to a callback function. It can be used for

getting additional information about the context in which the callback was

invoked.

#### *napi_callback*

Function pointer type for user-provided native functions which are to be

exposed to JavaScript via N-API. Callback functions should satisfy the

following signature:

```C

```

#### *napi_finalize*

Function pointer type for add-on provided functions that allow the user to be

notified when externally-owned data is ready to be cleaned up because the

object with which it was associated with, has been garbage-collected. The user

must provide a function satisfying the following signature which would get

called upon the object's collection. Currently, `napi_finalize` can be used for

finding out when objects that have external data are collected.

#### napi_async_execute_callback

Function pointer used with functions that support asynchronous

operations. Callback functions must statisfy the following signature:

```C

typedef void (*napi_async_execute_callback)(napi_env env, void* data);

```

#### napi_async_complete_callback

Function pointer used with functions that support asynchronous

operations. Callback functions must statisfy the following signature:

```C

typedef void (*napi_async_complete_callback)(napi_env env,

napi_status status,

void* data);

```

## Error Handling

N-API uses both return values and Javascript exceptions for error handling.

The following sections explain the approach for each case.

### Return values

All of the N-API functions share the same error handling pattern. The

return type of all API functions is `napi_status`.

The return value will be `napi_ok` if the request was successful and

no uncaught JavaScript exception was thrown. If an error occurred AND

an exception was thrown, the `napi_status` value for the error

will be returned. If an exception was thrown, and no error occurred,

`napi_pending_exception` will be returned.

In cases where a return value other than `napi_ok` or

`napi_pending_exception` is returned, [`napi_is_exception_pending`][]

must be called to check if an exception is pending.

See the section on exceptions for more details.

The full set of possible napi_status values is defined

in `napi_api_types.h`.

The `napi_status` return value provides a VM-independent representation of

the error which occurred. In some cases it is useful to be able to get

more detailed information, including a string representing the error as well as

VM (engine)-specific information.

In order to retrieve this information [`napi_get_last_error_info`][]

is provided which returns a `napi_extended_error_info` structure.

The format of the `napi_extended_error_info` structure is as follows:

```C

typedef struct napi_extended_error_info {

const char* error_message;

void* engine_reserved;

uint32_t engine_error_code;

napi_status error_code;

};

```

- `engine_reserved`: Opaque handle reserved for engine use only.

- `engine_error_code`: VM specific error code.

- `error_code`: n-api status code for the last error.

[`napi_get_last_error_info`][] returns the information for the last

N-API call that was made.

information as it is not subject to SemVer and may change at any time.

It is intended only for logging purposes.

#### napi_get_last_error_info

<!-- YAML

added: v8.0.0

-->

```C

NAPI_EXTERN napi_status

napi_get_last_error_info(napi_env env,

const napi_extended_error_info** result);

```

- `[in] env`: The environment that the API is invoked under.

- `[out] result`: The `napi_extended_error_info` structure with more

information about the error.

Returns `napi_ok` if the API succeeded.

This API retrieves a `napi_extended_error_info` structure with information

*Note*: The content of the `napi_extended_error_info` returned is only

valid up until an n-api function is called on the same `env`.

information as it is not subject to SemVer and may change at any time.

It is intended only for logging purposes.

### Exceptions

Any N-API function call may result in a pending JavaScript exception. This is

obviously the case for any function that may cause the execution of

JavaScript, but N-API specifies that an exception may be pending

on return from any of the API functions.

If the `napi_status` returned by a function is `napi_ok` then no

exception is pending and no additional action is required. If the

`napi_status` returned is anything other than `napi_ok` or

`napi_pending_exception`, in order to try to recover and continue

instead of simply returning immediately, [`napi_is_exception_pending`][]

must be called in order to determine if an exception is pending or not.

When an exception is pending one of two approaches can be employed.

The first appoach is to do any appropriate cleanup and then return so that

execution will return to JavaScript. As part of the transition back to

JavaScript the exception will be thrown at the point in the JavaScript

code where the native method was invoked. The behavior of most N-API calls

is unspecified while an exception is pending, and many will simply return

`napi_pending_exception`, so it is important to do as little as possible

and then return to JavaScript where the exception can be handled.

The second approach is to try to handle the exception. There will be cases

where the native code can catch the exception, take the appropriate action,

and then continue. This is only recommended in specific cases

where it is known that the exception can be safely handled. In these

cases [`napi_get_and_clear_last_exception`][] can be used to get and

clear the exception. On success, result will contain the handle to

the last JavaScript Object thrown. If it is determined, after

retrieving the exception, the exception cannot be handled after all

it can be re-thrown it with [`napi_throw`][] where error is the

JavaScript Error object to be thrown.

The following utility functions are also available in case native code

needs to throw an exception or determine if a `napi_value` is an instance

of a JavaScript `Error` object: [`napi_throw_error`][],

[`napi_throw_type_error`][], [`napi_throw_range_error`][] and

[`napi_is_error`][].

The following utility functions are also available in case native

code needs to create an Error object: [`napi_create_error`][],

[`napi_create_type_error`][], and [`napi_create_range_error`][].

where result is the napi_value that refers to the newly created

JavaScript Error object.

The Node.js project is adding error codes to all of the errors

generated internally. The goal is for applications to use these

error codes for all error checking. The associated error messages

will remain, but will only be meant to be used for logging and

display with the expectation that the message can change without

SemVer applying. In order to support this model with N-API, both

in internal functionality and for module specific functionality

(as its good practice), the `throw_` and `create_` functions

take an optional code parameter which is the string for the code

to be added to the error object. If the optional parameter is NULL

then no code will be associated with the error. If a code is provided,

the name associated with the error is also updated to be:

```

originalName [code]

```

where originalName is the original name associated with the error

and code is the code that was provided. For example if the code

is 'ERR_ERROR_1' and a TypeError is being created the name will be:

```

TypeError [ERR_ERROR_1]

```

#### napi_throw

<!-- YAML

added: v8.0.0

-->

```C

NODE_EXTERN napi_status napi_throw(napi_env env, napi_value error);

```

- `[in] env`: The environment that the API is invoked under.

- `[in] error`: The `napi_value` for the Error to be thrown.

Returns `napi_ok` if the API succeeded.

This API throws the JavaScript Error provided.

#### napi_throw_error

<!-- YAML

added: v8.0.0

-->

```C

NODE_EXTERN napi_status napi_throw_error(napi_env env,

const char* code,

const char* msg);

```

- `[in] env`: The environment that the API is invoked under.

- `[in] msg`: C string representing the text to be associated with

the error.

Returns `napi_ok` if the API succeeded.

This API throws a JavaScript Error with the text provided.

#### napi_throw_type_error

<!-- YAML

added: v8.0.0

-->

```C

NODE_EXTERN napi_status napi_throw_type_error(napi_env env,

const char* code,

const char* msg);

```

- `[in] env`: The environment that the API is invoked under.

- `[in] msg`: C string representing the text to be associated with

the error.

Returns `napi_ok` if the API succeeded.

This API throws a JavaScript TypeError with the text provided.

#### napi_throw_range_error

<!-- YAML

added: v8.0.0

-->

```C

NODE_EXTERN napi_status napi_throw_range_error(napi_env env,

const char* code,

const char* msg);

```

- `[in] env`: The environment that the API is invoked under.

- `[in] msg`: C string representing the text to be associated with

the error.

Returns `napi_ok` if the API succeeded.

This API throws a JavaScript RangeError with the text provided.

#### napi_is_error

<!-- YAML

added: v8.0.0

-->

```C

NODE_EXTERN napi_status napi_is_error(napi_env env,

napi_value value,

bool* result);

```

- `[in] env`: The environment that the API is invoked under.

- `[in] msg`: The `napi_value` to be checked.

- `[out] result`: Boolean value that is set to true if `napi_value` represents

an error, false otherwise.

Returns `napi_ok` if the API succeeded.

This API queries a `napi_value` to check if it represents an error object.

#### napi_create_error

<!-- YAML

added: v8.0.0

-->

```C

```

- `[in] env`: The environment that the API is invoked under.

- `[in] code`: Optional `napi_value` with the string for the error code to

be associated with the error.

- `[in] msg`: napi_value that references a JavaScript String to be

used as the message for the Error.

- `[out] result`: `napi_value` representing the error created.

Returns `napi_ok` if the API succeeded.

This API returns a JavaScript Error with the text provided.

#### napi_create_type_error

<!-- YAML

added: v8.0.0

-->

```C

```

- `[in] env`: The environment that the API is invoked under.

- `[in] code`: Optional `napi_value` with the string for the error code to

be associated with the error.

- `[in] msg`: napi_value that references a JavaScript String to be

used as the message for the Error.

- `[out] result`: `napi_value` representing the error created.

Returns `napi_ok` if the API succeeded.

This API returns a JavaScript TypeError with the text provided.

#### napi_create_range_error

<!-- YAML

added: v8.0.0

-->

```C

const char* msg,

napi_value* result);

```

- `[in] env`: The environment that the API is invoked under.

- `[in] code`: Optional `napi_value` with the string for the error code to

be associated with the error.

- `[in] msg`: napi_value that references a JavaScript String to be

used as the message for the Error.

- `[out] result`: `napi_value` representing the error created.

Returns `napi_ok` if the API succeeded.

This API returns a JavaScript RangeError with the text provided.

#### napi_get_and_clear_last_exception

<!-- YAML

added: v8.0.0

-->

```C

NAPI_EXTERN napi_status napi_get_and_clear_last_exception(napi_env env,

napi_value* result);

```

- `[in] env`: The environment that the API is invoked under.

- `[out] result`: The exception if one is pending, NULL otherwise.

Returns `napi_ok` if the API succeeded.

This API returns true if an exception is pending.

#### napi_is_exception_pending

<!-- YAML

added: v8.0.0

-->

```C

NAPI_EXTERN napi_status napi_is_exception_pending(napi_env env, bool* result);

```

- `[in] env`: The environment that the API is invoked under.

- `[out] result`: Boolean value that is set to true if an exception is pending.

Returns `napi_ok` if the API succeeded.

This API returns true if an exception is pending.

### Fatal Errors

In the event of an unrecoverable error in a native module, a fatal error can be

thrown to immediately terminate the process.

#### napi_fatal_error

<!-- YAML

-->

```C

NAPI_EXTERN NAPI_NO_RETURN void napi_fatal_error(const char* location, const char* message);

```

- `[in] location`: Optional location at which the error occurred.

- `[in] message`: The message associated with the error.

The function call does not return, the process will be terminated.

## Object Lifetime management

As N-API calls are made, handles to objects in the heap for the underlying

VM may be returned as `napi_values`. These handles must hold the

objects 'live' until they are no longer required by the native code,

otherwise the objects could be collected before the native code was

finished using them.

As object handles are returned they are associated with a

'scope'. The lifespan for the default scope is tied to the lifespan

of the native method call. The result is that, by default, handles

remain valid and the objects associated with these handles will be

held live for the lifespan of the native method call.

In many cases, however, it is necessary that the handles remain valid for

either a shorter or longer lifespan than that of the native method.

The sections which follow describe the N-API functions than can be used

to change the handle lifespan from the default.

### Making handle lifespan shorter than that of the native method

It is often necessary to make the lifespan of handles shorter than

the lifespan of a native method. For example, consider a native method

that has a loop which iterates through the elements in a large array:

```C

for (int i = 0; i < 1000000; i++) {

napi_value result;

napi_status status = napi_get_element(e object, i, &result);

if (status != napi_ok) {

break;

}

// do something with element

}

```

This would result in a large number of handles being created, consuming

substantial resources. In addition, even though the native code could only

use the most recent handle, all of the associated objects would also be

kept alive since they all share the same scope.

To handle this case, N-API provides the ability to establish a new 'scope' to

which newly created handles will be associated. Once those handles

are no longer required, the scope can be 'closed' and any handles associated

with the scope are invalidated. The methods available to open/close scopes are

[`napi_open_handle_scope`][] and [`napi_close_handle_scope`][].

N-API only supports a single nested hiearchy of scopes. There is only one

active scope at any time, and all new handles will be associated with that

scope while it is active. Scopes must be closed in the reverse order from

which they are opened. In addition, all scopes created within a native method

must be closed before returning from that method.

Taking the earlier example, adding calls to [`napi_open_handle_scope`][] and

[`napi_close_handle_scope`][] would ensure that at most a single handle

is valid throughout the execution of the loop:

```C

napi_handle_scope scope;

napi_status status = napi_open_handle_scope(env, &scope);

if (status != napi_ok) {

break;

}

napi_value result;

status = napi_get_element(e object, i, &result);

if (status != napi_ok) {

break;

}

// do something with element

status = napi_close_handle_scope(env, scope);

if (status != napi_ok) {

break;

}

}

```

When nesting scopes, there are cases where a handle from an

allows one handle to be 'promoted' so that it 'escapes' the

current scope and the lifespan of the handle changes from the current

scope to that of the outer scope.

The methods available to open/close escapable scopes are

[`napi_open_escapable_handle_scope`][] and [`napi_close_escapable_handle_scope`][].

The request to promote a handle is made through [`napi_escape_handle`][] which

can only be called once.

#### napi_open_handle_scope

<!-- YAML

added: v8.0.0

-->

```C

NODE_EXTERN napi_status napi_open_handle_scope(napi_env env,

napi_handle_scope* result);

```

- `[in] env`: The environment that the API is invoked under.

- `[out] result`: `napi_value` representing the new scope.

Returns `napi_ok` if the API succeeded.

This API open a new scope.

#### napi_close_handle_scope

<!-- YAML

added: v8.0.0

-->

```C

NODE_EXTERN napi_status napi_close_handle_scope(napi_env env,

napi_handle_scope scope);

```

- `[in] env`: The environment that the API is invoked under.

- `[in] scope`: `napi_value` representing the scope to be closed.

Returns `napi_ok` if the API succeeded.

This API closes the scope passed in. Scopes must be closed in the

reverse order from which they were created.

#### napi_open_escapable_handle_scope

<!-- YAML

added: v8.0.0

-->

```C

NODE_EXTERN napi_status

napi_open_escapable_handle_scope(napi_env env,

napi_handle_scope* result);

```

- `[in] env`: The environment that the API is invoked under.

- `[out] result`: `napi_value` representing the new scope.

Returns `napi_ok` if the API succeeded.

to the outer scope.

#### napi_close_escapable_handle_scope

<!-- YAML

added: v8.0.0

-->

```C

NODE_EXTERN napi_status

napi_close_escapable_handle_scope(napi_env env,

napi_handle_scope scope);

```

- `[in] env`: The environment that the API is invoked under.

- `[in] scope`: `napi_value` representing the scope to be closed.

Returns `napi_ok` if the API succeeded.

This API closes the scope passed in. Scopes must be closed in the

reverse order from which they were created.

#### napi_escape_handle

<!-- YAML

added: v8.0.0

-->

```C

NAPI_EXTERN napi_status napi_escape_handle(napi_env env,

napi_escapable_handle_scope scope,

napi_value escapee,

napi_value* result);

```

- `[in] env`: The environment that the API is invoked under.

- `[in] scope`: `napi_value` representing the current scope.

- `[in] escapee`: `napi_value` representing the JavaScript Object to be escaped.

- `[out] result`: `napi_value` representing the handle to the escaped

Object in the outer scope.

Returns `napi_ok` if the API succeeded.

This API promotes the handle to the JavaScript object so that it is valid

for the lifetime of the outer scope. It can only be called once per scope.

If it is called more than once an error will be returned.

### References to objects with a lifespan longer than that of the native method

In some cases an addon will need to be able to create and reference objects

with a lifespan longer than that of a single native method invocation. For

example, to create a constructor and later use that constructor

in a request to creates instances, it must be possible to reference

the constructor object across many different instance creation requests. This

would not be possible with a normal handle returned as a `napi_value` as

described in the earlier section. The lifespan of a normal handle is

managed by scopes and all scopes must be closed before the end of a native

method.

N-API provides methods to create persistent references to an object.

Each persistent reference has an associated count with a value of 0

or higher. The count determines if the reference will keep

the corresponding object live. References with a count of 0 do not

prevent the object from being collected and are often called 'weak'

references. Any count greater than 0 will prevent the object

from being collected.

References can be created with an initial reference count. The count can

then be modified through [`napi_reference_ref`][] and

[`napi_reference_unref`][]. If an object is collected while the count

for a reference is 0, all subsequent calls to

get the object associated with the reference [`napi_get_reference_value`][]

will return NULL for the returned `napi_value`. An attempt to call

[`napi_reference_ref`][] for a reference whose object has been collected

will result in an error.

References must be deleted once they are no longer required by the addon. When

a reference is deleted it will no longer prevent the corresponding object from

being collected. Failure to delete a persistent reference will result in

a 'memory leak' with both the native memory for the persistent reference and

the corresponding object on the heap being retained forever.

There can be multiple persistent references created which refer to the same

object, each of which will either keep the object live or not based on its

individual count.

#### napi_create_reference

<!-- YAML

added: v8.0.0

-->

```C

NODE_EXTERN napi_status napi_create_reference(napi_env env,

napi_value value,

int initial_refcount,

```

- `[in] env`: The environment that the API is invoked under.

- `[in] value`: `napi_value` representing the Object to which we want

a reference to.

- `[in] initial_refcount`: Initial reference count for the new reference.

- `[out] result`: `napi_ref` pointing to the new reference.

Returns `napi_ok` if the API succeeded.

This API create a new reference with the specified reference count

to the Object passed in.

#### napi_delete_reference

<!-- YAML

added: v8.0.0

-->

```C

NODE_EXTERN napi_status napi_delete_reference(napi_env env, napi_ref ref);

```

- `[in] env`: The environment that the API is invoked under.

- `[in] ref`: `napi_ref` to be deleted.

Returns `napi_ok` if the API succeeded.

This API deletes the reference passed in.

#### napi_reference_ref

<!-- YAML

added: v8.0.0

-->

```C

NODE_EXTERN napi_status napi_reference_ref(napi_env env,

napi_ref ref,

int* result);

```

- `[in] env`: The environment that the API is invoked under.

- `[in] ref`: `napi_ref` for which the reference count will be incremented.

- `[out] result`: The new reference count.

Returns `napi_ok` if the API succeeded.

This API increments the reference count for the reference

passed in and returns the resulting reference count.

#### napi_reference_unref

<!-- YAML

added: v8.0.0

-->

```C

NODE_EXTERN napi_status napi_reference_unref(napi_env env,

napi_ref ref,

int* result);

```

- `[in] env`: The environment that the API is invoked under.

- `[in] ref`: `napi_ref` for which the reference count will be decremented.

- `[out] result`: The new reference count.

Returns `napi_ok` if the API succeeded.

This API decrements the reference count for the reference

passed in and returns the resulting reference count.

#### napi_get_reference_value

<!-- YAML

added: v8.0.0

-->

```C

NODE_EXTERN napi_status napi_get_reference_value(napi_env env,

napi_ref ref,

napi_value* result);

```

the `napi_value passed` in or out of these methods is a handle to the

object to which the reference is related.

- `[in] env`: The environment that the API is invoked under.

- `[in] ref`: `napi_ref` for which we requesting the corresponding Object.

- `[out] result`: The `napi_value` for the Object referenced by the

`napi_ref`.

Returns `napi_ok` if the API succeeded.

If still valid, this API returns the `napi_value` representing the

JavaScript Object associated with the `napi_ref`. Otherise, result

will be NULL.

## Module registration

N-API modules are registered in the same manner as other modules

except that instead of using the `NODE_MODULE` macro the following

is used:

```C

NAPI_MODULE(addon, Init)

```

The next difference is the signature for the `Init` method. For a N-API

module it is as follows:

```C

void Init(napi_env env, napi_value exports, napi_value module, void* priv);

```