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.
Before the change a negative input offset would lead to memory unsafe
behavior. This is correct as such because a negative input offset
should never happen (so an assert is sufficient). However, the compiler
saves and restores lexer "points" to and from duk_tval numbers, so if
duk_tval representation is chosen improperly or something similar happens,
the input offset could be corrupted (again, this is only the case if
something is pretty badly wrong anyway).
The new behavior is to throw an internal error for negative input offsets.
This is explicit and memory safe, and protects against potential compiler
bugs too.