[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: future of bytecode verifier
- From: askok@...
- Date: Thu, 05 Mar 2009 16:27:32 +0200
I used to be a proponent of the "Lua should hide
endianess" issue, but not so any more.
The reason is that I've noticed building all precompiled
chunks always _inside_ the C/C++ binary. And if I do this,
endianess is no longer an issue anyways.
Do you others really have .lch files that are loaded off
the disk, at runtime?
On Thu, 05 Mar 2009 09:06:13 -0500
Ralph Hempel <email@example.com> wrote:
John Hind wrote:
This approach makes Lua "safe by default" and anyone
support is made responsible for the integrity of the
bytecodes between write
and read operations (for example by restricting to a
protected store, or
even by implementing cryptographic signing).
Can I also request that consideration be given to
sorting out the
"endedness" problem for Lua bytecode? Either pick an
endedness for the saved
format and convert if necessary on both write and read,
or if this is
thought inefficient, have a flag for the endedness in
the format and convert
on read if necessary.
Going to the next incremental minor number has usually
been the point
where breakage might occur, so 5.2 seems as good a place
as any to get
this sorted out.