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