|
|
|
--- !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
|
|
|
|
- ""
|