Re: future of bytecode verifier

[Luiz Henrique de Figueiredo <lhf@...>]

> 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).

This would break existing programs, though. And it'd be policy not mechanisms,
while Lua goes for the oposite.
 
> Can I also request that consideration be given to sorting out the
> "endedness" problem for Lua bytecode?

As discussed before, the portability issues in the bytecode format are not
restricted to endianness. I've also explained here that it's simple to write
your own bytecode format -- you just have to edit ldump.c and lundump.c,
and just the low-level functions.

> have a flag for the endedness in the format

It's there already.

> One of the benefits of bytecode should be full support for
> heterogeneous computing platforms

The one really portable Lua format is source. Really. The parser is very
fast as it is. But I see your point, of course.