Re: [patch] fix luai_num* null states

[Lourival Vieira Neto <lourival.neto@...>]

On Mon, Mar 3, 2014 at 6:46 PM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> I was working on redefining of luai_num* macros on Lua 5.3 work1 for
>> disabling float point operations and I realized that these macros are
>> not working properly when they try to access the given Lua state;
>> mainly because lcode.c and lobject.c pass a null state for them. Here
>> is a small patch to fix this.
>
> Why do you need the Lua state in those macros?

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?

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

Anyway, I think it would be a good practice to always pass a
consistent Lua state to luai_num macros, because the Lua state is an
argument of them.

Regards,
-- 
Lourival Vieira Neto