 |
lua-l archive |
|
|
||
|
On 30/07/2011 20.00, Luiz Henrique de Figueiredo wrote:
moreover it could change from version to version, so you would have to rewrite the function for each new Lua release.Given that new Lua versions are rare, this does not seem to be a real problem.
Fair enough.
Sorry for the bad wording, for the sake of shortness I oversimplified. I really meant different builds of the same implementation (different because either of the platform, toolchain or C runtime).it would very important to react _at runtime_ in a reliable way to the different implementations of the interpreter.As stated in the manual, Lua numbers are double-precision floating-point numbers. Different implementations of the interpreter are probably not that common.
The problem here, as pointed out by Roberto, is that doubles aren't used for everything under the hood and sometimes the integer type used internally "surfaces" into Lua. So, as reasonably stated by Roberto, there must be a compromise in order to avoid too many checks and overhead. But this implies, IMHO, that the programmer should at least know exactly in which cases this could happen (even if it doesn't actually happen because it depends on different platform/toolchain/etc.).
Anyway if the method used by Liam of parsing the bytecode header is robust enough, then this is part of the solution. The other part is knowing where are the critical points in Lua where that could happen (e.g. which functions and which args).