[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [patch] changing lua_Number to int64_t
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
>>> 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:
Main Index |
Thread Index |