On 3 Dec 2013 22:16, "Lourival Vieira Neto" <lneto%netbsd.org@localhost> wrote:
>
> Hi Justin,
>
> On Tue, Dec 3, 2013 at 8:04 PM, Justin Cormack
> <justin%specialbusservice.com@localhost> wrote:
> >
> > On 3 Dec 2013 16:02, "Christos Zoulas" <christos%zoulas.com@localhost> wrote:
> >>
> >> On Dec 3, 11:45am, lneto%netbsd.org@localhost (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?
>
If the Lua int type was 128 bit uint64_t would convert differently. More correctly even as it would remain unsigned rather than wrapping to signed. This means code will break as the kernel uses uint64_t.
We always have a 64 bit type as you need it to eg read a filesystem. It may be emulated by the compiler but it works.