Re: CVS commit: src

[Lourival Vieira Neto <lneto%netbsd.org@localhost>]

On Tue, Dec 3, 2013 at 9:26 PM, Alexander Nasonov <alnsn%yandex.ru@localhost> 
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