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.
DUK_UINTPTR_MAX, DUK_UINTMAX_MAX, and related signed variants had incorrect
values for the case where standard C99 int types were not available, platform
was 64-bit (this probably happened in GH-15). This would lead duk_features.h
to incorrectly deduce that a packed duk_tval was possible.
Combined with the related duk_tval vs. sizeof(void *) self test, this case
should now be much better covered.
Signed integer constants like -0x80000000L are not portable. The reason is
somewhat hairy, see code-issues.txt for a detailed discussion. This fix
changes such constants to computed values (like -0x7fffffffL - 1L) to avoid
portability issues related to signed/unsigned integers.
This fixes a concrete bug on VS2010 + X64 (GH-15).
This non-standard behavior is now enabled by default. A feature option
needs to be added to disable it in case it causes problems for some users
(quite unlikely).
Some limitations of duk_hobject_define_property_internal() (which is
ultimately called by duk_def_prop_xxx()) are not obvious and were only
asserted for. Change the asserts into actual checks so that if there
is a call site which makes an incorrect assumption (perhaps in some
corner case), an error is thrown instead of something unsafe happening.
Previous change to use duk_def_prop_xxx() instead of duk_prop_put_xxx()
broke 'length' of parsed result arrays. Since duk_def_prop_xxx() don't
automatically update 'length', it was left unset.
With put_prop variant Duktape would incorrectly parse a JSON object
containing a '__proto__' named property. Such a property must be
parsed as a plain property and must not affect the object's prototype
(ES6 inherited __proto__ property).
Also change call sites to use these macros. For now, the macros just
call the existing def_prop_xxx() functions, but because there are
relatively many call sites, these can be footprint optimized later.