On Sun, Nov 17, 2013 at 9:30 AM, Alexander Nasonov <al...@yandex.ru> wrote: > Mouse wrote: >> Also, using an exact-width type assumes that the hardware/compiler in >> question _has_ such a type. >> >> It's possible that lua, NetBSD, or the combination of the two is >> willing to write off portability to machines where one or both of those >> potential portability issues becomes actual. But that seems to be >> asking for trouble to me; history is full of "but nobody will ever want >> to port this to one of _those_" that come back to bite people. > > I was perfectly fine with long long because it's long enough to > represent all integers in range [-2^53-1, 2^53-1]. > > As Marc pointed out, Lua has a single numeric type which is double > by default. Many Lua libraries don't need FP and they use a subset of > exactly representable integers (not all of them do range checks, though). > Extending the range when porting from userspace to kernel will decrease > "the pain factor" of porting.
I think that it is not the main point here, to decrease the "pain factor" of porting. Porting Lua user-space libraries should be painful enough independently of lua_Number type. IMHO, the main point here is to define a lua_Number type adjusted to kernel needs. As, we have already broke compatibility with user space libraries (for several factors, not only the missing of floating point number), I think it shouldn't matter much now. Regards, -- Lourival Vieira Neto