On Tue, Dec 3, 2013 at 9:26 PM, Alexander Nasonov <al...@yandex.ru> wrote: > Lourival Vieira Neto wrote: >> I wasn't in that thread at that time. However, I'll carefully read it. > > If you haven't done so yet, it's a good idea to subscribe to > source-changes-d@.
Yes, I subscribed already =). I just hadn't at that time. >> Anyway, I think that the missing implementation of luai_numpow() >> doesn't break anything. > > Do you have a test to prove that 'return 2^3' doesn't break in the > kernel? Yes; you can just load the script you've mentioned. There is no reason to break anything. It is just defined as the multiplication operator. >> Is there an issue with lua_error? > > I don't think that lua_error would work because lua_State isn't passed > to luai_numpow(a,b). I wanted to say that you need a stub that breaks > in a very noticeable way. I really miss your point here. Why lua_State should be passed to luai_numpow()? Anyway, I just checked and lua_error is working fine. Do you have an example that breaks it? If you want a verbose output, just push your error message (like, lua_pushstring(L, "my error")) and call lua_error(L). If kern.lua.verbose is set, you will get "my error" printed. >> I don't think I've created a problem to myself. We discussed it on the >> list and _we_ come to a conclusion. Note, I don't think that this >> overflow is a huge problem. The worst that could happen is to have a >> truncation of a greater number instead of 0. Anyway, I think it must >> be fixed and that any of the two presented solutions is fine. However, >> I also have no problem to step back and use 'long long', if _we_ >> choose to reconsider that. IMHO, the fact that Lua 5.3 is using 'long >> long' is a good argument for that. I do prefer explicit width type, >> but my main argument is that 'long long' width could be lesser than 64 >> bit. > > Lua is external software and we should keep our copy close to the > original. If this sense long long is the best choice. However, Lua > 5.3 isn't released yet and Lua team may change their minds. They will > have to go through similar problem with strtoll replacement, though. I agree, we should keep the implementation close to the original. However, the whole point about luaconf.h is to adapt Lua without changing its implementation. IMO, we should choose the best LUA_NUMBER type for us. In this case, I think it is intmax_t (as already stated by Christos), if we won't use a fixed width type. Regards, -- Lourival Vieira Neto