On Sun, Nov 17, 2013 at 10:10 AM, Justin Cormack <jus...@specialbusservice.com> wrote: > 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.
Indeed. Regards, -- Lourival Vieira Neto