From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 72DA0A0547; Fri, 12 Mar 2021 18:37:56 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1EF041608C7; Fri, 12 Mar 2021 18:37:55 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id 3091F1608C6 for ; Fri, 12 Mar 2021 18:37:52 +0100 (CET) IronPort-SDR: uL3uKXjrvnE3295dZlNRVSDgqLAcUHnynhHW9ELcbIHlQnB911amtCHW9dwYK/Ls+vzGVXn6rl EVX1yWbCyVCQ== X-IronPort-AV: E=McAfee;i="6000,8403,9921"; a="188908238" X-IronPort-AV: E=Sophos;i="5.81,244,1610438400"; d="scan'208";a="188908238" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Mar 2021 09:37:51 -0800 IronPort-SDR: 04+1NVjsskYO4UuHBpPz/9sXoGQX9JHA/1xIh64lqPQ7LHh7zJC31IeQFxbPJv009nj6G03L9j BYKMpfXPZILg== X-IronPort-AV: E=Sophos;i="5.81,244,1610438400"; d="scan'208";a="404491074" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.11.209]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 12 Mar 2021 09:37:49 -0800 Date: Fri, 12 Mar 2021 17:37:41 +0000 From: Bruce Richardson To: Tyler Retzlaff Cc: "Burakov, Anatoly" , dev@dpdk.org, david.hunt@intel.com Message-ID: <20210312173741.GC937@bricha3-MOBL.ger.corp.intel.com> References: <1615333490-15243-1-git-send-email-roretzla@linux.microsoft.com> <9ab8e965-b2ec-d554-d167-e3ed62ed62de@intel.com> <20210312170558.GA8084@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210312170558.GA8084@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> Subject: Re: [dpdk-dev] [PATCH] eal, power: don't use '-' sign with unsigned literals X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Mar 12, 2021 at 09:05:58AM -0800, Tyler Retzlaff wrote: > On Fri, Mar 12, 2021 at 12:51:46PM +0000, Burakov, Anatoly wrote: > > On 09-Mar-21 11:44 PM, Tyler Retzlaff wrote: > > >use ~0ULL instead of -1ULL to avoid contridctory application of '-' sign > > >to integer literal where the desired type is unsigned. > > > > > >Signed-off-by: Tyler Retzlaff > > >--- > > > > Not sure i agree. It's a very common pattern and is widely used and > > understood. I mean, if anything, seeing `~0` would have me stop and > > think as i've literally never seen such code before. > > it produces warnings under some compilers. in some enterprises we are > required to fix certain classes of warnings (not suppress them from the > command line) as a function of security policies. > > as an alternative would you be more willing to accept something like the > following? ``(unsigned long long)-1LL'' if you don't like ``~0ULL'' it > would make explicit what the compiler is already doing. > > the issue is the application of the sign to what is clearly something not > signed; it get's flagged. so the cast is an explicit expression of intent > that will not generate the warnings. > > appreciate you're help in finding a solution even if it isn't the > proposed solution. > What about using ULLONG_MAX and similar defines from limits.h?