In these situations the new size being allocated can't be zero, so the call
site can just compare the result pointer and assume NULL means error. It's
not an obvious thing so add an explicit comment and an assert.
Discovered with GC torture testing: when mark-and-sweep is triggered during a
realloc, the realloc() retry handler does not handle zero size correctly (i.e.
it doesn't accept a NULL as a successful result in that case).
After these fixes GC torture tests pass.
Add (draft) release notes for the 1.0 release. The intent is for the release
notes of a stable version to be up-to-date so one can see known issues and
workarounds at a glance.
Quick hack test for a mstrix compile test. This rudimentary test revealed a
few compile warning issues which are fixed separately.
For proper coverage the test matrices will be very large, so a random
sampling approach is probably the most useful to quickly go through a lot of
variations. The test matrix could then include basically every compiler and
feature option in isolation (creating billions of combinations) as well as
every testcase Duktape has. For a given test matrix configuration one integer
can be used to identify a combination and easily report and repeat failures.
Fix some compile warnings mostly related to GCC -O4. The GCC -O4 result is
not clean when assertions are enabled; the remaining warnings seem spurious
and difficult to silence in a reasonable way.
Unused variables in some option combinations. Some of these were caused by
having -DDUK_OPT_DEBUG but no debug print options.
The GCC -O4 array subscript warning seems spurious and is probably caused by
GCC not being 100% sure 'count' is always valid. The call sites for
duk__advance_chars() have a variety of argument values, including those
computed using shifts etc. Add an explicit check for the valid range which
silences the GCC error. The check also protects against regressions that
would cause an invalid count to be used. With the check in place,
potentially memory unsafe behavior will now cause an internal error instead.
If the form DUK_ASSERT(x >= 0 && x < y) is used, gcc will cause a spurious
warning:
duk_api_stack.c:149:33: error: assuming signed overflow does not occur when assuming that (X - c) > X is always false [-Werror=strict-overflow]
duk_error.h:131:8: note: in definition of macro ‘DUK_ASSERT’
By breaking down the assert into two, i.e. DUK_ASSERT(x >= 0) and
DUK_ASSERT(x < y) the warning disappears.
When one mark-and-sweep round leaves objects-to-be-finalized on the heap
finalize_list, the next round must treat them like reachability roots to
ensure any objects they point to get marked reachable.
The REACHABLE flag was cleared for objects-to-be-finalized when they were
moved from the heap_allocated list to the finalize_list. This is correct
if finalizers are executed afterwards. But when finalizers are skipped,
the next mark-and-sweep will mark the objects on the finalize_list REACHABLE
which broke some assertions. Fix that by clearing REACHABLE flags for
objects on the finalize_list explicitly after sweeping. This overlaps with
the existing code in the sweep phase in a harmless way.
This solution is a minimal fix to the issue. In Duktape 1.1 the intent is
to rework mark-and-sweep so that finalizer execution can be independent of
mark-and-sweep, so a root canal fix wouldn't be useful at this point.
Add an example of a C module into the guide, even if there is not strongly
recommended module convention. These conventions will be worked out probably
for the 1.1 release, together with a suggested DLL format for major platforms.
Together, these will allow modules to be more easily exchanged between code
bases as pre-packaged binaries and such.