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/