 |
lua-l archive |
|
|
||
|
On 30/07/2011 12.17, liam mail wrote:
On 29 July 2011 20:21, Lorenzo Donati <lorenzodonatibz@interfree.it <mailto:lorenzodonatibz@interfree.it>> wrote:
[...]
vm_details = function() local env = string.dump(function()end) assert(env:byte(6) == 0x00)--if hit then it is not an official Lua release local number_type local int_width if env:byte(12) == 0x0 then if env:byte(11) == 0x08 then number_type = 'double' elseif env:byte(11) == 0x04 then number_type = 'float' else number_type = 'unknown' end else number_type = 'int type of size ' .. tonumber(env:byte(11)) end return number_type, tonumber(env:byte(8)) end
I don't understand it fully. It seems that this relies on the internal VM or bytecode format, which is not formalized anywhere, so you cannot rely on that - moreover it could change from version to version, so you would have to rewrite the function for each new Lua release. (BTW int_width is not used, a typo or what?)
My suggestion of adding those (ugly) constants for fundamental implementation limits is just because to avoid undefined behaviour. If there were a constant such as _IMPLICIT_INT_WIDTH (or whatever) *its meaning* would be clear and foolproof and no more implementation defined or undefined (of course *its value* would).
Of course suggestions are welcome to improve my proposal, but the point is: for complex, portable, pure-lua scripts, it would very important to react _at runtime_ in a reliable way to the different implementations of the interpreter. I know that Lua team tries to abstract over the implementation and don't like implementation details to leak in Lua, but those unexpected integer overflow are implementation leaks.
As for the problem of adding fat to Lua, all those limits could be put in another library (limits.bit_width, limits.num_type?, etc.) which people with more space constraint could avoid including (I'm thinking of embedded systems people, now). For the others, a few bytes shouldn't be a problem (how much could a handful of carefully selected constants impact on Lua code size?).
Please, I don't love this proposal. I know it is ugly indeed. But real world is ugly sometimes, and IMO it's better for scripts to be allowed to react to this ugliness in a deterministic way (as I said, any better solution is welcome, if robust enough).
-- Lorenzo