Re: [patch] changing lua_Number to int64_t

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

On Sun, Nov 17, 2013 at 10:10 AM, Justin Cormack
<justin%specialbusservice.com@localhost> wrote:
> 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.

Indeed.

Regards,
-- 
Lourival Vieira Neto