On Sun, Nov 17, 2013 at 4:52 PM, Lourival Vieira Neto <lourival.n...@gmail.com> wrote: > On Sun, Nov 17, 2013 at 2:02 PM, Christos Zoulas <chris...@zoulas.com> wrote: >> On Nov 17, 10:46am, lourival.n...@gmail.com (Lourival Vieira Neto) wrote: >> -- Subject: Re: [patch] changing lua_Number to int64_t >> >> | On Sun, Nov 17, 2013 at 7:37 AM, Marc Balmer <m...@msys.ch> 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