From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DD9EEC433B4 for ; Fri, 21 May 2021 12:02:09 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 5E49461261 for ; Fri, 21 May 2021 12:02:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5E49461261 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 64DA640686; Fri, 21 May 2021 14:02:08 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 14EA140143 for ; Fri, 21 May 2021 14:02:06 +0200 (CEST) IronPort-SDR: 6FD8uWrrH7h/9h5ysHYmZj2SrirjUd/+hulFdgYH3hCYTwa49i/JDbgWDj/jLn5jvsPwMBD0u0 FeIMObugI4Tg== X-IronPort-AV: E=McAfee;i="6200,9189,9990"; a="188865534" X-IronPort-AV: E=Sophos;i="5.82,319,1613462400"; d="scan'208";a="188865534" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 May 2021 05:02:04 -0700 IronPort-SDR: i1gfIxMbQYS1DZNDA0oYDFHBqhNe8nkiTDfpmkQBwvV4FX6UqF54dawugaKRcDwHHcxLXwY/zZ GJsFErL3+P2g== X-IronPort-AV: E=Sophos;i="5.82,319,1613462400"; d="scan'208";a="412580017" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.210.36]) ([10.213.210.36]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 May 2021 05:02:03 -0700 To: Thomas Monjalon , dev@dpdk.org References: <20210209152643.1832506-1-ferruh.yigit@intel.com> <20210519192449.2688051-1-thomas@monjalon.net> From: Ferruh Yigit X-User: ferruhy Message-ID: <4ed3f134-a54d-9993-704b-6de1157f5fae@intel.com> Date: Fri, 21 May 2021 13:01:57 +0100 MIME-Version: 1.0 In-Reply-To: <20210519192449.2688051-1-thomas@monjalon.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] devtools: check %l format specifier 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 5/19/2021 8:24 PM, Thomas Monjalon wrote: > From: Ferruh Yigit > > %lx or %llx tend to be wrong for 32-bit platform > if used for fixed size variable like uint64_t. > A checkpatch warning will avoid this common mistake. > > Signed-off-by: Ferruh Yigit > Signed-off-by: Thomas Monjalon > --- > v2: proposal to reword the message and comment > --- > devtools/checkpatches.sh | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh > index db4c7d8301..0e09b2cab8 100755 > --- a/devtools/checkpatches.sh > +++ b/devtools/checkpatches.sh > @@ -69,6 +69,14 @@ check_forbidden_additions() { # > -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \ > "$1" || res=1 > > + # check %l or %ll format specifier > + awk -v FOLDERS='lib drivers app examples' \ > + -v EXPRESSIONS='%ll*[xud]' \ > + -v RET_ON_FAIL=1 \ > + -v MESSAGE='Using %l format, should it be %PRI*64?' \ > + -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \ > + "$1" || res=1 > + > # forbid variable declaration inside "for" loop > awk -v FOLDERS='.' \ > -v EXPRESSIONS='for[[:space:]]*\\((char|u?int|unsigned|s?size_t)' \ > Using the %l or %ll format specifier is correct when the variable type is "long int" or "long long int", it is only wrong if the variable type is fixed size like 'unit64_t'. My concern is above warning log may cause people change the correct usage. That was why I tried to make wording less strict, more like a reminder to double check the usage. If we can check that format specifier is used for 'unit64_t' variable, that will be the best solution but that is very hard to do. Should we add a little more information to the message to prevent false hit on the correct usage?