Stack types

Duktape stack types are:

Memory allocations

The following stack types involve additional heap allocations:

• String: a single allocation contains a combined heap and string header, followed by the immutable string data.
• Object: one allocation is used for a combined heap and object header, and another allocation is used for object properties. The property allocation contains both array entries and normal properties, and if the object is large enough, a hash table to speed up lookups.
• Buffer: for fixed buffers a single allocation contains a combined heap and buffer header, followed by the mutable fixed-size buffer. For dynamic buffers the current buffer is allocated separately.

Note that while strings are considered a primitive (pass-by-value) type in Ecmascript, they are a heap allocated type from a memory allocation viewpoint.

Pointer stability

Heap objects allocated by Duktape have stable pointers: the objects are not relocated in memory while they are reachable from a garbage collection point of view. This is the case for the main heap object, but not necessarily for any additional allocations related to the object, such as dynamic property tables or dynamic buffer data area. A heap object is reachable e.g. when it resides on the value stack of a reachable thread or is reachable through the global object. Once a heap object becomes unreachable any pointers held by user C code referring to the object are unsafe and should no longer be dereferenced.

In practice the only heap allocated data directly referenced by user code are strings, fixed buffers, and dynamic buffers. The data area of strings and fixed buffers is stable; it is safe to keep a C pointer referring to the data even after a Duktape/C function returns as long the string or fixed buffer remains reachable from a garbage collection point of view at all times. Note that this is not usually not the case for Duktape/C value stack arguments, for instance, unless specific arrangements are made.

The data area of a dynamic buffer does not have a stable pointer. The buffer itself has a heap header with a stable address but the current buffer is allocated separately and potentially relocated when the buffer is resized. It is thus unsafe to hold a pointer to a dynamic buffer's data area across a buffer resize, and it's probably best not to hold a pointer after a Duktape/C function returns (how would you reliably know when the buffer is resized?).

Type masks

Type masks allows calling code to easily check whether a type belongs to a certain type set. For instance, to check that a certain stack value is a number, string, or an object:

if (duk_get_type_mask(ctx, -3) & (DUK_TYPE_MASK_NUMBER |
                                  DUK_TYPE_MASK_STRING |
                                  DUK_TYPE_MASK_OBJECT)) {
    printf("type is number, string, or object\n");
}

There is a specific API call for matching a set of types even more conveniently:

if (duk_check_type_mask(ctx, -3, DUK_TYPE_MASK_NUMBER |
                                 DUK_TYPE_MASK_STRING |
                                 DUK_TYPE_MASK_OBJECT)) {
    printf("type is number, string, or object\n");
}

These are faster and more compact than the alternatives:

// alt 1
if (duk_is_number(ctx, -3) || duk_is_string(ctx, -3) || duk_is_object(ctx, -3)) {
    printf("type is number, string, or object\n");
}

// alt 2
int t = duk_get_type(ctx, -3);
if (t == DUK_TYPE_NUMBER || t == DUK_TYPE_STRING || t == DUK_TYPE_OBJECT) {
    printf("type is number, string, or object\n");
}

None

The none type is not actually a type but is used in the API to indicate that a value does not exist, a stack index is invalid, etc.

Undefined

The undefined type maps to Ecmascript undefined, which is distinguished from a null.

Values read from outside the active value stack range read back as undefined.

Null

The null type maps to Ecmascript null.

Boolean

The boolean type is represented in the C API as an integer: zero for false, and non-zero for true.

Whenever giving boolean values as arguments in API calls, any non-zero value is accepted as a "true" value. Whenever API calls return boolean values, the value 1 is always used for a "true" value. This allows certain C idioms to be used. For instance, a bitmask can be built directly based on API call return values, as follows:

// this works and generates nice code
int bitmask = (duk_get_boolean(ctx, -3) << 2) |
              (duk_get_boolean(ctx, -2) << 1) |
              duk_get_boolean(ctx, -1);

// more verbose variant not relying on "true" being represented by 1
int bitmask = ((duk_get_boolean(ctx, -3) ? 1 : 0) << 2) |
              ((duk_get_boolean(ctx, -2) ? 1 : 0) << 1) |
              (duk_get_boolean(ctx, -1) ? 1 : 0);

// another verbose variant
int bitmask = (duk_get_boolean(ctx, -3) ? (1 << 2) : 0) |
              (duk_get_boolean(ctx, -2) ? (1 << 1) : 0) |
              (duk_get_boolean(ctx, -1) ? 1 : 0);

Number

The number type is an IEEE double, including +/- Infinity and NaN values. Zero sign is also preserved. An IEEE double represents all integers up to 53 bits accurately.

IEEE double allows NaN values to have additional signaling bits. Because these bits are used by Duktape internal tagged type representation (when using 8-byte packed values), NaN values in the Duktape API are normalized. Concretely, if you push a certain NaN value to the value stack, another (normalized) NaN value may come out. Don't rely on NaNs preserving their exact form.

String

The string type is a raw byte sequence of a certain length which may contain internal NUL (0x00) values. Strings are always automatically NUL terminated for C coding convenience. The NUL terminator is not counted as part of the string length. For instance, the string "foo" has byte length 3 and is stored in memory as { 'f', 'o', 'o', '\0' }. Because of the guaranteed NUL termination, strings can always be pointed to using a simple const char * as long as internal NULs are not an issue; if they are, the explicit byte length of the string can be queried with the API. Calling code can refer directly to the string data held by Duktape. Such string data pointers are valid (and stable) for as long as a string is reachable in the Duktape heap.

Strings are interned for efficiency: only a single copy of a certain string ever exists at a time. Strings are immutable and must NEVER be changed by calling C code. Doing so will lead to very mysterious issues which are hard to diagnose.

Calling code most often deals with Ecmascript strings, which may contain arbitrary 16-bit codepoints (the whole range 0x0000 to 0xFFFF) but cannot represent non-BMP codepoints (this is how strings are defined in the Ecmascript standard). In Duktape, Ecmascript strings are encoded with CESU-8 encoding. CESU-8 matches UTF-8 except that it allows codepoints in the surrogate pair range (U+D800 to U+DFFF) to be encoded directly; these are prohibited in UTF-8. CESU-8, like UTF-8, encodes all 7-bit ASCII characters as-is which is convenient for C code. For example:

• U+0041 ("A") encodes to 41.
• U+1234 (ETHIOPIC SYLLABLE SEE) encodes to e1 88 b4.
• U+D812 (high surrogate) encodes to ed a0 92 (this would be invalid UTF-8).

Duktape also allows extended strings internally. Codepoints up to U+10FFFF can be represented with UTF-8, and codepoints above that up to full 32 bits can be represented with "extended UTF-8". Non-standard strings are used for storing internal object properties; using a non-standard string ensures that such properties never conflict with properties accessible using standard Ecmascript strings. Non-standard strings can be given to Ecmascript built-in functions, but since behavior may not be exactly specified, results may vary.

Duktape uses internal object properties to record internal implementation related fields in e.g. function objects. For example, a finalizer reference is stored in an internal finalizer property. Such internal keys are kept separate from valid Ecmascript keys by using a byte sequence which can never occur in a valid CESU-8 string; consequently, standard Ecmascript code cannot accidentally reference such fields. Internal properties are never enumerable, and are not returned by e.g. Object.getOwnPropertyNames(). Currently, internal property names begin with an 0xFF byte followed by the property name. For instance the finalizer property key consists of the byte 0xFF followed by the ASCII string "finalizer". In internal documentation this property would usually be referred to as _finalizer for convenience. You should never read or write internal properties directly.

The "extended UTF-8" encoding used by Duktape is described in the table below. The leading byte is shown in binary (with "x" marking data bits) while continuation bytes are marked with "C" (indicating the bit sequence 10xxxxxx):

The downside of the encoding for codepoints above U+7FFFFFFF is that the leading byte will be 0xFE which conflicts with Unicode byte order marker encoding. This is not a practical concern in Duktape's internal use.

Object

The object type includes Ecmascript objects and arrays, functions, and threads (coroutines). In other words, anything with properties is an object. Properties are key-value pairs with a string key and an arbitrary value (including undefined).

Objects may participate in garbage collection finalization.

Buffer

The buffer type is a raw buffer for user data of either fixed or dynamic size. The size of a fixed buffer is given at its creation, and fixed buffers have an unchanging (stable) data pointer. Dynamic buffers may change during their life time at the cost of having a (potentially) changing data pointer. Dynamic buffers also need two memory allocations internally, while fixed buffers only need one.

Buffers are automatically garbage collected. This also means that C code must not hold onto a buffer data pointer unless the buffer is reachable to Duktape, e.g. resides in an active value stack.

The buffer type is not standard Ecmascript. There are a few different Ecmascript typed array specifications, though, see e.g. Typed Array Specification. These will be implemented on top of raw arrays, most likely.

Pointer

The pointer type is a raw, uninterpreted C pointer, essentially a void *. Pointers can be used to point to native objects (memory allocations, handles, etc), but because Duktape doesn't know their use, they are not automatically garbage collected. You can, however, put one or more pointers inside an object and use the object finalizer to free the native resources related to the pointer(s).