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 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C5D4FC433EF for ; Wed, 22 Jun 2022 11:09:45 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.353785.580767 (Exim 4.92) (envelope-from ) id 1o3yEd-00077B-UW; Wed, 22 Jun 2022 11:09:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 353785.580767; Wed, 22 Jun 2022 11:09:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1o3yEd-000774-RH; Wed, 22 Jun 2022 11:09:23 +0000 Received: by outflank-mailman (input) for mailman id 353785; Wed, 22 Jun 2022 11:09:22 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1o3yEc-00076y-Gw for xen-devel@lists.xenproject.org; Wed, 22 Jun 2022 11:09:22 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id c33dca3b-f21b-11ec-b725-ed86ccbb4733; Wed, 22 Jun 2022 13:09:19 +0200 (CEST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4D71013D5; Wed, 22 Jun 2022 04:09:19 -0700 (PDT) Received: from [10.57.38.102] (unknown [10.57.38.102]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 658DB3F66F; Wed, 22 Jun 2022 04:09:18 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c33dca3b-f21b-11ec-b725-ed86ccbb4733 Message-ID: Date: Wed, 22 Jun 2022 13:09:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH 9/9] drivers/acpi: Use explicitly specified types Content-Language: en-US To: Jan Beulich Cc: xen-devel@lists.xenproject.org References: <20220620070245.77979-1-michal.orzel@arm.com> <20220620070245.77979-10-michal.orzel@arm.com> <155d8f62-aece-8fb8-8be2-6d21d20926d7@suse.com> From: Michal Orzel In-Reply-To: <155d8f62-aece-8fb8-8be2-6d21d20926d7@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 22.06.2022 12:36, Jan Beulich wrote: > On 20.06.2022 09:02, Michal Orzel wrote: >> According to MISRA C 2012 Rule 8.1, types shall be explicitly >> specified. Fix all the findings reported by cppcheck with misra addon >> by substituting implicit type 'unsigned' to explicit 'unsigned int'. >> >> Signed-off-by: Michal Orzel >> --- >> This patch may not be applicable as these files come from Linux. > > We've diverged quite far, so the Linux origin isn't really a concern > (anymore). > Ok. >> --- a/xen/drivers/acpi/tables/tbfadt.c >> +++ b/xen/drivers/acpi/tables/tbfadt.c >> @@ -235,7 +235,7 @@ void __init acpi_tb_create_local_fadt(struct acpi_table_header *table, u32 lengt >> ACPI_WARNING((AE_INFO, >> "FADT (revision %u) is longer than ACPI 5.0 version," >> " truncating length %u to %zu", >> - table->revision, (unsigned)length, >> + table->revision, (unsigned int)length, > > Since we generally try to avoid casts where not needed - did you consider > dropping the cast here instead of fiddling with it? Aiui this wouldn't be > a problem since we assume sizeof(int) >= 4 and since types more narrow > than int would be converted to int (which in turn is generally printing > okay with %u). Strictly speaking it would want to be PRIu32 ... > The reason I did not consider it was to make the review process easier by performing only the mechanical change being part of fixing 8.1 rule. However I'm fully ok to drop the cast. Changing the format specifier to PRIu32 for length would require using PRIu8 for table->revision to be coherent. >> --- a/xen/drivers/acpi/tables/tbutils.c >> +++ b/xen/drivers/acpi/tables/tbutils.c >> @@ -481,7 +481,7 @@ acpi_tb_parse_root_table(acpi_physical_address rsdp_address, u8 flags) >> if (ACPI_FAILURE(status)) { >> ACPI_WARNING((AE_INFO, >> "Truncating %u table entries!", >> - (unsigned) >> + (unsigned int) >> (acpi_gbl_root_table_list.size - >> acpi_gbl_root_table_list. >> count))); > > Same here then, except PRIu32 wouldn't be correct to use in this case. > Why is it so given that both size and count are of type u32? > Jan Cheers, Michal