Re: [patch] changing lua_Number to int64_t

[Marc Balmer <marc%msys.ch@localhost>]

Am 17.11.13 11:18, schrieb Alexander Nasonov:
> Lourival Vieira Neto wrote:
>> 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.
> 
> Portability with userspace will arise as soon as you decide to import
> some Lua library to kernel space. If kernel number type is wide enough
> to represent all exactly representable integers from userspace, you have
> less worries.

The basic issue here is that Lua has only _one_ numerical data type,
which is an integral type in kernel, but a floating point type in userspace.

> Also, some libraries work in both spaces. Lua binding for proplib(3) is
> a good example.

Yes, if one keeps above issue in mind, a script can be written for both
use cases.  speaking of a proplib(3) binding, is that code available
somewhere?

> 
>>> 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?
> 
> See above. If they switch to long double, they will extend integer
> arithmetic range.
> 
>>> 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?
> 
> I'm not sure why. It may be related to user-defined literals:
> http://akrzemi1.wordpress.com/2012/08/12/user-defined-literals-part-i/