Re: [patch] changing lua_Number to int64_t

[Justin Cormack <justin%specialbusservice.com@localhost>]

On Sun, Nov 17, 2013 at 11: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.

The range [-2^53-1, 2^53-1] is not sufficient - in kernel you need to
be able to deal with the longest type the kernel uses, it is
incredibly annoying to have to use userdata to deal with off_t or
gratuitously hope that losing some bits is ok (as happens with Lua in
userspace now). As the widest type in the kernel is int64_t thats
what Lua should use. (The issue of uint64_t is left as an exercise for
the Lua programmer). When/if the kernel uses something longer then Lua
can change, but using intmax_t is not useful as the kernel is explicit
about sizes.

Justin