Re: [patch] fix luai_num* null states

[Roberto Ierusalimschy <roberto@...>]

> To properly handle div and mod by zero, throwing an error on the Lua
> state. I am defining lua_Number as lua_Integer. For that, I've defined
> luai_num{div,mod,pow} as luaV_{div,mod,pow}. This approach sounds to
> work fine, except by the frexp() function. I defined it temporarily as
> an inline stub function, which seems to work but I don't think it is a
> good solution because it leads to different hash functions for
> lua_Number and lua_Integer. I'll take a deeper look to try to find a
> better way to make lua_Number have the same behaviour of lua_Integer.
> Do you have any tip?

It is not enough to change the macros. Currently, the compiler uses
those macros to do constant folding, but the compiler should not raise
an error in a division by zero, as it cannot know whether the division
will ever be executed. We will have to change the compiler, too.

Another approach would be to avoid having values of type "lua_Number" in
the first place.  As far as I see, a lua_Number can only be created in 4
cases (if we assume there are no previous lua_Numbers):

- by the parser
- by a float division
- by a coersion from a string to a number
- by lua_pushnumber

Maybe the core could have some macros to control that. (You probably
would need something for the parser anyway; what does it do when
the code contains a floating-point constant?)


> I had another small issue on luaV_numtointeger(). I had an 'integer
> overflow' on the line 81 of lvm.c. I solved as follows:
> 
> -  if (cast_num(MIN_INTEGER) <= n && n < (MAX_INTEGER + cast_num(1))) {
> +  if (cast_num(MIN_INTEGER) <= n && (n - cast_num(1)) < MAX_INTEGER) {

This is tricky... In my machine, this change does not pass the standard
tests for vanilla Lua (64-bit floats and integers). (I am trying to figure
out why, but when I add some printfs to the code, it works again; weird...)

-- Roberto