issue-5a475183756ef2d8cbcd187284cffa41062ce093.yaml

--- !ditz.rubyforge.org,2008-03-06/issue 
title: option to memzero freed memory blocks
desc: ""
type: :task
component: duk
release: 
reporter: sva <sami.vaarala@iki.fi>
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 <sami.vaarala@iki.fi>
  - created
  - ""
- - 2014-01-22 18:13:49.930422 Z
  - sva <sami.vaarala@iki.fi>
  - 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 <sami.vaarala@iki.fi>
  - 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.
- - 2014-05-14 17:05:31.156827 Z
  - Sami Vaarala <sami.vaarala@iki.fi>
  - unassigned from release v0.11
  - ""