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.
 
 
 
 
 
 

49 lines
1.8 KiB

--- !ditz.rubyforge.org,2008-03-06/issue
title: optional bytecode load/save primitives
desc: ""
type: :task
component: duk
release: v1.2
reporter: Sami Vaarala <sami.vaarala@iki.fi>
status: :unstarted
disposition:
creation_time: 2014-05-13 20:41:40.423599 Z
references: []
id: b39a1fec201f4a846d611fff8735f52388b9f13b
log_events:
- - 2014-05-13 20:41:40.574073 Z
- Sami Vaarala <sami.vaarala@iki.fi>
- created
- ""
- - 2014-05-13 20:42:49.555987 Z
- Sami Vaarala <sami.vaarala@iki.fi>
- commented
- Also make the compiler configurable, to reduce footprint.
- - 2014-07-30 10:52:02.483037 Z
- Sami Vaarala <sami.vaarala@iki.fi>
- assigned to release v0.12 from unassigned
- ""
- - 2014-07-30 10:55:47.371843 Z
- Sami Vaarala <sami.vaarala@iki.fi>
- commented
- |-
One interesting question is to whether or not allow duk_compile() and duk_eval()
(and variants) to transparently load/execute bytecode. If allowed, it will make
module loading a bit easier because the caller doesn't need to check a file for a
bytecode signature. On the other hand because bytecode is not verified, it makes
loading unsafe remote code easy too - which means that when loading remote code,
user code should exclude bytecode based on signature manually.
Perhaps the best option is to allow bytecode loading when an explicit flag is
given to duk_compile(). Another option is to make the bytecode primitives
entirely separate: duk_bytecode_dump(), duk_bytecode_load(). User should be able
to load bytecode from a buffer (like with duk_compile()).
- - 2014-08-22 08:46:20.458669 Z
- Sami Vaarala <sami.vaarala@iki.fi>
- assigned to release v1.1 from v0.12
- ""
- - 2014-11-07 21:13:50.991980 Z
- Sami Vaarala <sami.vaarala@iki.fi>
- assigned to release v1.2 from v1.1
- ""