You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

45 lines
1.6 KiB

11 years ago
--- !ditz.rubyforge.org,2008-03-06/issue
title: option to memzero freed memory blocks
desc: ""
type: :task
component: duk
release: v0.11
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.