RE: [patch] changing lua_Number to int64_t

["Terry Moore" <tmm%mcci.com@localhost>]

> From: Lourival Vieira Neto [mailto:lourival.neto%gmail.com@localhost]
> > Watch out, by the way, for compiled scripts; I have not checked Lua 5.x,
but
> > you may find if not careful that the compiled binary is not loadable on
> > machines with different choices for LP64, ILP32, etc. This is somewhat
> > independent of the choice of lua_Number mapping.
> 
> Yes, Lua bytecode isn't portable in fact. BTW, loading Lua bytecode is
> not recommended by Lua team. It isn't safe.

It's not *much* less safe than compiling and executing a string in the
kernel. The only additional attack surfaces are that you can write things
that the compiler wouldn't write. This can (1) cause a crash at load time,
or it can (2) cause surprising behavior later. 

I suspect that anyone who would want to allow Lua in the kernel would be
somewhat indifferent to type-2 safety issues. If you don't trust the input
string, you had better not give it to the kernel (whether or not it's
compiled). Type-1 safety issues ought to be fixed, as careful examination of
the input data only slows down the load process -- it has no run-time
effects. 

Given that Lua byte codes can be translated into C arrays and then loaded
via the API, portability issues can creep in through the back door. 

Best regards,
--Terry