On Tue, Dec 3, 2013 at 8:15 PM, Lourival Vieira Neto <ln...@netbsd.org> wrote: > Hi Justin, > > On Tue, Dec 3, 2013 at 8:04 PM, Justin Cormack > <jus...@specialbusservice.com> wrote: >> >> On 3 Dec 2013 16:02, "Christos Zoulas" <chris...@zoulas.com> wrote: >>> >>> On Dec 3, 11:45am, ln...@netbsd.org (Lourival Vieira Neto) wrote: >>> -- Subject: Re: CVS commit: src >>> >>> | Also, moving to intmax_t, would help in string library. It needs a >>> | length modifier for string.format (LUA_INTFRMLEN). AFAIK, there is no >>> | length modifier defined for int64_t. Using intmax_t we could just use >>> | "j". >>> >>> Yes, the other good side effect of intmax_t is that this is "the best >>> the machine" can do in terms of integer range. >>> >> >> No that is a bad side effect. It must always be 64 bits. In the kernel you >> have to deal with uint64_t which will behave differently if intmax_t is ever >> bigger than 64 bits, so code will break. So either use int64_t or what Lua >> uses and assert that that is 64 bits. > > What side effect? Why it must always be 64 bit? Also, I don't get the > unsigned problem. What it will break? Moreover, if we don't have a > 64-bit int type, what we should do? Disable Lua?
just got the 'side effect' part.. =) -- Lourival Vieira Neto
