Re: [patch] changing lua_Number to int64_t

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

On Sun, Nov 17, 2013 at 4:52 PM, Lourival Vieira Neto
<lourival.neto%gmail.com@localhost> wrote:
> On Sun, Nov 17, 2013 at 2:02 PM, Christos Zoulas 
> <christos%zoulas.com@localhost> wrote:
>> On Nov 17, 10:46am, lourival.neto%gmail.com@localhost (Lourival Vieira Neto) 
>> wrote:
>> -- Subject: Re: [patch] changing lua_Number to int64_t
>>
>> | On Sun, Nov 17, 2013 at 7:37 AM, Marc Balmer <marc%msys.ch@localhost> 
>> wrote:
>> | > Am 17.11.13 04:49, schrieb Terry Moore:
>> | >> I believe that if you want the Lua scripts to be portable across NetBSD
>> | >> deployments, you should choose a well-known fixed width.
>> | >
>> | > I don't see this as very important.  Lua scripts will hardly depend on
>> | > the size of an integer.
>> |
>> | But they could. I think that the script programmers should know if the
>> | numeric data type is enough for their usage (e.g., time diffs).
>>
>> By making it the biggest type possible, you never need to be worried.
>
> Right.. you just convinced me.. if no one opposes, I'll change that to
> intmax_t and get rid of PRI/SCNd64 =).

1. Lua 5.3 will have 64 bit integer support as standard, which will
make interop and reuse between kernel and userspace code much easier,
iff we use int64_t

2. Code will have to handle use in the kernel of uint64_t which will
potentially behave differently with Lua number type being int64_t vs
if it was sat int128_t which might happen, such that its unlikely to
be tested properly. There is no existing system where intmax_t is not
int64_t so this breakage is untestable.

Justin