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 134E6C07E97 for ; Tue, 5 Dec 2023 16:25:59 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.648124.1012139 (Exim 4.92) (envelope-from ) id 1rAYEw-00078j-6S; Tue, 05 Dec 2023 16:25:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 648124.1012139; Tue, 05 Dec 2023 16:25:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rAYEw-00078c-3u; Tue, 05 Dec 2023 16:25:42 +0000 Received: by outflank-mailman (input) for mailman id 648124; Tue, 05 Dec 2023 16:25:41 +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 1rAYEv-00077J-DM for xen-devel@lists.xenproject.org; Tue, 05 Dec 2023 16:25:41 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id edd6dff0-938a-11ee-98e5-6d05b1d4d9a1; Tue, 05 Dec 2023 17:25:40 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id 9CD2E4EE0741; Tue, 5 Dec 2023 17:25:39 +0100 (CET) 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: edd6dff0-938a-11ee-98e5-6d05b1d4d9a1 MIME-Version: 1.0 Date: Tue, 05 Dec 2023 17:25:39 +0100 From: Nicola Vetrini To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v2] x86/DMI: adjustments to comply with Misra C:2012 Rule 9.3 In-Reply-To: <1ca903e7-ed2c-435e-999d-2a8519957498@suse.com> References: <1ca903e7-ed2c-435e-999d-2a8519957498@suse.com> Message-ID: <4d4c07c874575ab09d96f5dcfceeeff7@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi Jan, On 2023-12-05 14:35, Jan Beulich wrote: > The rule demands that all array elements be initialized (or dedicated > initializers be used). Introduce a small set of macros to allow doing > so > without unduly affecting use sites (in particular in terms of how many > elements .matches[] actually has; right now there's no use of > DMI_MATCH4(), so we could even consider reducing the array size to 3). > > Signed-off-by: Jan Beulich > --- > Of course a question is how many of these DMI table entries are in fact > no longer applicable (e.g. because of naming 32-bit-only systems). > Subsequently the table in dmi_scan.c itself may want cleaning up as > well, yet I guess the question of stale entries is even more relevant > there. > --- > v2: Make things also build with older gcc. > Analyzed with ECLAIR for Rule 9.3: resolves all the violations related to DMI_MATCH. -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com)