Source-Changes-D archive

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

Re: CVS commit: src



On Tue, Dec 3, 2013 at 8:15 PM, 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?

just got the 'side effect' part.. =)
-- 
Lourival Vieira Neto


Home | Main Index | Thread Index | Old Index