--- !ditz.rubyforge.org,2008-03-06/issue title: option to memzero freed memory blocks desc: "" type: :task component: duk release: v0.11 reporter: sva status: :unstarted disposition: creation_time: 2014-01-22 18:11:50.962871 Z references: [] id: 5a475183756ef2d8cbcd187284cffa41062ce093 log_events: - - 2014-01-22 18:11:51.178826 Z - sva - created - "" - - 2014-01-22 18:13:49.930422 Z - sva - commented - |- Right now, Duktape doesn't always know the allocation size of a buffer being freed. If this were changed, zeroing could be implemented trivially. Duktape should know the alloc size of all buffers now: heap objects have a fixed size, strings and buffers have an explicit buffer size, property part allocation size can be computed, etc. However, there are quite many call sites to change. Another alternative is to wrap all allocations with a Duktape custom header containing the buffer size. This is quite awkward. - - 2014-01-22 18:15:09.649452 Z - sva - commented - |- There are about 30 ALLOC/REALLOC sizes in the code base, so not that many to fix actually. The macros should take the "current size" argument but this probably should not be provided to the user memory primitives. Instead, when using zeroing, Duktape would use an intermediate function which zeroed the allocation and then called the user function. When zeroing is not in use, the size argument can be dropped during compilation so that call site size does not increase unnecessarily.