The duk_idx_t type is appropriate for stack sizes and counts because
it will necessarily have enough bits to express sizes/counts nicely.
Negative values are clamped to zero or cause an error to be thrown.
This is nice for calling code, because calculation errors or simple
failures to clamp will not cause a negative value to be treated like
a large unsigned value which would be incorrect and lead to confusing
behavior.
The duk_uarridx_t type is unsigned and there might be a need for a signed
array index type later (duk_arridx_t would then be used). This convention
matches duk_ucodepoint_t and duk_codepoint_t.
Change array type back to unsigned (accidentally changed to signed
previously). Make codepoint types "fast integer" variants, as they're
used in loops and such, and are not used in significant structs. This
increases code footprint by ~200 bytes but is the better choice as it
also simplifies API typing.
Note: use duk_ret_t for function/method/safe call returns, and use
duk_bool_t for "C boolean" returns, where the return value range would
be the same as e.g. a comparison (a > b).
Use duk_compile_lstring() instead of duk_compile_userbuffer() to remain
consistant with the rest of the API. The variant which doesn't automagic
the filename argument is duk_compile_lstring_filename(). Similarly for
eval.
String variants referred to both 'src' and 'DUK_STRLEN(src)' which would
cause double evaluation of macro arguments. For instance, if 'src' was
obtained from a call to a function, the function would be called twice.
Fixed by taking the strlen() inside duk_api_compile.c. Not the most elegant
thing as it would be nicer to push this to the caller's footprint, but there
is no reasonably way of doing that with C expression syntax.
Compile from user buffer without interning. The current API is probably
not final because it defaults result fileName from __FILE__ which may not
be appropriate in general (cf. duk_compile() where caller provides the
fileName explicitly).
The cost of this change is minimal (e.g. on x64, ~100 bytes) but it's
something that would quite easily crop up on exotic platforms. Fixing
it without tinkering with Duktape internals would be difficult for the
calling code.