[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49D32E7A.7000209@panasas.com>
Date: Wed, 01 Apr 2009 12:06:02 +0300
From: Benny Halevy <bhalevy@...asas.com>
To: Boaz Harrosh <bharrosh@...asas.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
Jeff Garzik <jeff@...zik.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
James Bottomley <James.Bottomley@...senPartnership.com>,
Avishay Traeger <avishay@...il.com>,
open-osd <osd-dev@...n-osd.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Evgeniy Polyakov <zbr@...emap.net>
Subject: Re: [osd-dev] [PATCH 6/8] exofs: super_operations and file_system_type
On Apr. 01, 2009, 11:05 +0300, Boaz Harrosh <bharrosh@...asas.com> wrote:
> On 03/31/2009 09:52 PM, Benny Halevy wrote:
>> On Mar. 31, 2009, 11:04 +0300, Andrew Morton <akpm@...ux-foundation.org> wrote:
>>> ~0 is signed 0xffffffff.
>>>
>>> When assigning to a u64 it gets signed extended to signed
>>> 0xffffffffffffffff and then converted to unsigned 0xffffffffffffffff.
>> Right (I think, I'm not sure in what order)
>>
>>> I think. Just as with plain old "-1". Perhaps using plain old "-1"
>>> would be clearer here.
>> or maybe ~0ULL or ~(uint64_t)0 to be extremely anal about it.
>>
>> Benny
>>
>
> There is only one right way => ULLONG_MAX. Takes care of the human factor
> too. (BTW that one is defined (~0ULL))
Ideally, since the variable is a uint64_t, you'd want a U64_MAX.
unsigned long long may, at some point, be larger than uint64 on
some architectures. With the available defs ~(uint64_t)0 or even
just ~0 seem more portable...
Benny
>
> Thanks
> Boaz
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists