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 a 256-byte table for hex decoding. This affects several places
where hex values were decoded with an if-else ladder. There's some
net footprint increase. Performance increases are mostly limited to
duk_decode_hex() API call and Duktape.dec('jx', ...) calls. Elsewhere
the performance matters less.
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.