Re: future of bytecode verifier

[askok@...]

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?

- asko


On Thu, 05 Mar 2009 09:06:13 -0500
 Ralph Hempel <rhempel@hempeldesigngroup.com> wrote:
> John Hind wrote:
>
> > This approach makes Lua "safe by default" and anyone 
> > implementing bytecode
> > 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).
>
> Strongly agree.
>
> > 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.
>
> Strongly agree.
>
> 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.
>
> Ralph