Re: CVS commit: src

[Alexander Nasonov <alnsn%yandex.ru@localhost>]

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@.

> 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?

> 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 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.

Alex