tech-kern archive

[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:

Home | Main Index | Thread Index | Old Index