From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benny Halevy Subject: Re: [osd-dev] [PATCH 6/8] exofs: super_operations and file_system_type Date: Wed, 01 Apr 2009 12:06:02 +0300 Message-ID: <49D32E7A.7000209@panasas.com> References: <49C1331D.1080805@panasas.com> <1237399791-29502-1-git-send-email-bharrosh@panasas.com> <20090331010430.72e8137e.akpm@linux-foundation.org> <49D2665A.9090500@panasas.com> <49D32041.4090009@panasas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Andrew Morton , FUJITA Tomonori , Jeff Garzik , linux-kernel , James Bottomley , Avishay Traeger , open-osd , linux-fsdevel , Evgeniy Polyakov To: Boaz Harrosh Return-path: In-Reply-To: <49D32041.4090009@panasas.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Apr. 01, 2009, 11:05 +0300, Boaz Harrosh wrote: > On 03/31/2009 09:52 PM, Benny Halevy wrote: >> On Mar. 31, 2009, 11:04 +0300, Andrew Morton 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 >