Re: [patch] changing lua_Number to int64_t

[Lourival Vieira Neto <lourival.neto%gmail.com@localhost>]

On Sun, Nov 17, 2013 at 9:30 AM, Alexander Nasonov <alnsn%yandex.ru@localhost> 
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