Re: [patch] changing lua_Number to int64_t

[Lourival Vieira Neto <lourival.neto%gmail.com@localhost>]

On Sat, Nov 16, 2013 at 9:47 PM, Alexander Nasonov <alnsn%yandex.ru@localhost> 
wrote:
> Lourival Vieira Neto wrote:
>> On Sat, Nov 16, 2013 at 8:52 PM, Christos Zoulas 
>> <christos%astron.com@localhost> wrote:
>> > In article <52872B0C.5080309%msys.ch@localhost>, Marc Balmer  
>> > <marc%msys.ch@localhost> wrote:
>> >>Changing the number type to int64_t is certainly a good idea.  Two
>> >>questions, however:
>> >
>> > Why not intmax_t?
>>
>> My only argument is that int64_t has a well-defined width and, AFAIK,
>> intmax_t could vary. But I have no strong feelings about this. Do you
>> think intmax_t would be better?
>
> int64_t should be enough to cover a range of exactly representable
> integers in userspace Lua program where lua_Number is double.

I don't think that keeping compatibility with userspace Lua is the
right argument. We already have lost this kind of compatibility by
using an integer type for lua_Number. Expecting that kernel lua_Number
works just like userspace lua_Numbers could lead to misunderstandings.

> I don't see a need for bigger type unless mainstream Lua switches to
> long double. I don't expect it to happen any time soon.

Why it should bother if Lua switches to a bigger floating-point type?

> PS Why do you still use a shadow copy of luaconf.h? Please add your
> changes to the main luaconf.h.

Only because it is the way that it was committed. I didn't take time
yet to unify that. But you are right, I'll try to do that in the
future.

> If you guard your kernel changes properly
> with _KERNEL, they will not affect userspace.

Yes, I know. I think the guards are just fine.

> PPS "%"PRId64 may break in C++11, space between the literals should fix it.

I don't think that are plans to change kernel language to C++ ;-),
however doesn't hurt to write it in "clean" C.

Just for curiosity.. do you know why it is not allowed in C++11?

Regards,
-- 
Lourival Vieira Neto