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 310EDC001DE for ; Fri, 4 Aug 2023 07:12:52 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.576925.903618 (Exim 4.92) (envelope-from ) id 1qRozH-0005v2-Pp; Fri, 04 Aug 2023 07:12:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 576925.903618; Fri, 04 Aug 2023 07:12:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qRozH-0005uv-N4; Fri, 04 Aug 2023 07:12:39 +0000 Received: by outflank-mailman (input) for mailman id 576925; Fri, 04 Aug 2023 07:12:38 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qRozG-0005up-RC for xen-devel@lists.xenproject.org; Fri, 04 Aug 2023 07:12:38 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4a5e9e27-3296-11ee-b26a-6b7b168915f2; Fri, 04 Aug 2023 09:12:37 +0200 (CEST) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id 934424EE0737; Fri, 4 Aug 2023 09:12:36 +0200 (CEST) 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: 4a5e9e27-3296-11ee-b26a-6b7b168915f2 MIME-Version: 1.0 Date: Fri, 04 Aug 2023 09:12:36 +0200 From: Nicola Vetrini To: Jan Beulich Cc: Stefano Stabellini , xen-devel@lists.xenproject.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn?= =?UTF-8?Q?=C3=A9?= , Wei Liu Subject: Re: [XEN PATCH 01/11] x86/efi: move variable declaration to address MISRA C:2012 Rule 2.1 In-Reply-To: <3af75576-4a34-ab0e-3c1a-20a143e993e8@suse.com> References: <3af75576-4a34-ab0e-3c1a-20a143e993e8@suse.com> User-Agent: Roundcube Webmail/1.4.3 Message-ID: X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 03/08/2023 10:57, Jan Beulich wrote: > On 03.08.2023 04:08, Stefano Stabellini wrote: >> On Wed, 2 Aug 2023, Nicola Vetrini wrote: >>> The variable declaration is moved where it's actually used, rather >>> than being declared in the switch before any clause, thus being >>> classified as unreachable code. >>> >>> No functional changes. >>> >>> Signed-off-by: Nicola Vetrini >>> --- >>> xen/arch/x86/efi/efi-boot.h | 5 ++--- >>> 1 file changed, 2 insertions(+), 3 deletions(-) >>> >>> diff --git a/xen/arch/x86/efi/efi-boot.h >>> b/xen/arch/x86/efi/efi-boot.h >>> index 92f4cfe8bd..b00441b1a2 100644 >>> --- a/xen/arch/x86/efi/efi-boot.h >>> +++ b/xen/arch/x86/efi/efi-boot.h >>> @@ -390,8 +390,6 @@ static void __init efi_arch_edd(void) >>> { >>> switch ( DevicePathType(devp.DevPath) ) >>> { >>> - const u8 *p; >>> - >>> case ACPI_DEVICE_PATH: >>> if ( state != root || boot_edd_info_nr > >>> EDD_INFO_MAX ) >>> break; >>> @@ -463,7 +461,8 @@ static void __init efi_arch_edd(void) >>> params->device_path_info_length = >>> sizeof(struct edd_device_params) - >>> offsetof(struct edd_device_params, key); >>> - for ( p = (const u8 *)¶ms->key; p < >>> ¶ms->checksum; ++p ) >>> + for ( const u8 *p = (const u8 *)¶ms->key; >>> + p < ¶ms->checksum; ++p ) >> >> In Xen we don't mix declaration and code. So the following is not >> something we use: >> >> for (int i = 0; i < 10; i++) > > You're aware that we gained a couple of such uses already? I also think > that when we discussed this we said this style could be at least > okay-ish (until formalized in ./CODING_STYLE). > > What I'm unhappy with here is the retaining of u8, when it could easily > become uint8_t at this occasion. > > Jan Sure -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com)