Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759290AbZDAJGX (ORCPT ); Wed, 1 Apr 2009 05:06:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750903AbZDAJGK (ORCPT ); Wed, 1 Apr 2009 05:06:10 -0400 Received: from gw-ca.panasas.com ([209.116.51.66]:10287 "EHLO laguna.int.panasas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750704AbZDAJGI (ORCPT ); Wed, 1 Apr 2009 05:06:08 -0400 Message-ID: <49D32E7A.7000209@panasas.com> Date: Wed, 01 Apr 2009 12:06:02 +0300 From: Benny Halevy User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Boaz Harrosh CC: Andrew Morton , FUJITA Tomonori , Jeff Garzik , linux-kernel , James Bottomley , Avishay Traeger , open-osd , linux-fsdevel , Evgeniy Polyakov Subject: Re: [osd-dev] [PATCH 6/8] exofs: super_operations and file_system_type 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> In-Reply-To: <49D32041.4090009@panasas.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2009 09:06:05.0765 (UTC) FILETIME=[16BFB750:01C9B2A9] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1222 Lines: 35 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/