Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src



Hi Alexander,

On Mon, Dec 2, 2013 at 8:38 PM, Alexander Nasonov <alnsn%yandex.ru@localhost> 
wrote:
> Lourival Vieira Neto wrote:
>> Yes, it isn't. But, please note, I didn't change that now. I just
>> merged it in one single file. Though I think we need implement integer
>> exponentiation, I think that is not a priority. IMO, it is a TODO.
>
> Well, I assume that any raised issues should be resolved before moving
> broken stuff around. See the link to my review below.

I wasn't in that thread at that time. However, I'll carefully read it.
Anyway, I think that the missing implementation of luai_numpow()
doesn't break anything. Yes, of course, a*b != pow(a,b); but, it was
left in that way just for convenience. I don't see this as a main
issue anyhow.

> If you wanted to keep this item in TODO list, you'd better picked
> lua_error rather than lua_mul ;-)

Is there an issue with lua_error? Anyway, having two different
luaconf.h was a real issue. I have problems including the wrong header
with a little more complex Lua kmods (such as luadata). In fact, all
Lua kmods were including the wrong luaconf.h file, because of the
order of inclusion (-I's on Makefile). It didn't explode because they
weren't using lua_Number, but I had a real hard time trying to debug
this on luadata, once that compiling a kmod that uses a double type
isn't raising an error on amd64 (don't know why).

>> > 2. If intmax_t is a greater type than int64_t, the below doesn't
>> > handle overflow:
>> > #define lua_str2number(s,p)    ((int64_t) strtoimax((s), (p), 10))
>>
>> I'm considering two approaches:
>>
>> 1) creating an auxiliary function based on strtoimax():
> ...
>> 2) creating an auxiliary function based on strtol template
>
> I think you created some problems for yourself by using int64_t. I was
> going to tell you that Lua 5.3 uses long long for 64bit integers but I
> saw your question on lua-l about it.
>
> I didn't mind using long long in the kernel when we discussed that topic
> but some other people convinced you to use explicit width type ;-)

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.

Regards,
-- 
Lourival Vieira Neto


Home | Main Index | Thread Index | Old Index