Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src



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?

Regards,
-- 
Lourival Vieira Neto


Home | Main Index | Thread Index | Old Index