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 AE2D7C001B0 for ; Wed, 16 Aug 2023 10:01:31 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.584298.914838 (Exim 4.92) (envelope-from ) id 1qWDKx-0008U2-8h; Wed, 16 Aug 2023 10:01:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 584298.914838; Wed, 16 Aug 2023 10:01:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qWDKx-0008Tv-4Q; Wed, 16 Aug 2023 10:01:11 +0000 Received: by outflank-mailman (input) for mailman id 584298; Wed, 16 Aug 2023 10:01:10 +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 1qWDKw-0008Te-Kd for xen-devel@lists.xenproject.org; Wed, 16 Aug 2023 10:01:10 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d028ad4f-3c1b-11ee-9b0c-b553b5be7939; Wed, 16 Aug 2023 12:01:05 +0200 (CEST) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id 9FC654EE0737; Wed, 16 Aug 2023 12:01:04 +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: d028ad4f-3c1b-11ee-9b0c-b553b5be7939 MIME-Version: 1.0 Date: Wed, 16 Aug 2023 12:01:04 +0200 From: Nicola Vetrini To: Jan Beulich Cc: Stefano Stabellini , michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, Andrew Cooper , George Dunlap , Julien Grall , Wei Liu , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH 07/11] xen: address MISRA C:2012 Rule 2.1 In-Reply-To: References: <7f8cbd8c8ad64cd3a0d099f31cb4d3fad48aa63b.1690985045.git.nicola.vetrini@bugseng.com> <3a6ab847-fd31-60e4-2558-feed71d670dd@suse.com> User-Agent: Roundcube Webmail/1.4.3 Message-ID: <6e1dbf093687e5fa66295621ce67e4dc@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, On 08/08/2023 11:03, Nicola Vetrini wrote: > On 04/08/2023 08:42, Jan Beulich wrote: >> On 04.08.2023 01:50, Stefano Stabellini wrote: >>> On Thu, 3 Aug 2023, Jan Beulich wrote: >>>> On 02.08.2023 16:38, Nicola Vetrini wrote: >>>>> Rule 2.1 states: "A project shall not contain unreachable code". >>>>> >>>>> The functions >>>>> - machine_halt >>>>> - maybe_reboot >>>>> - machine_restart >>>>> are not supposed to return, hence the following break statement >>>>> is marked as intentionally unreachable with the >>>>> ASSERT_UNREACHABLE() >>>>> macro to justify the violation of the rule. >>>> >>>> During the discussion it was mentioned that this won't help with >>>> release builds, where right now ASSERT_UNREACHABLE() expands to >>>> effectively nothing. You want to clarify here how release builds >>>> are to be taken care of, as those are what eventual certification >>>> will be run against. >>> >>> Something along these lines: >>> >>> ASSERT_UNREACHABLE(), not only is used in non-release builds to >>> actually >>> assert and detect errors, but it is also used as a marker to tag >>> unreachable code. In release builds ASSERT_UNREACHABLE() doesn't >>> resolve >>> into an assert, but retains its role of a code marker. >>> >>> Does it work? >> >> Well, it states what is happening, but I'm not convinced it satisfies >> rule 2.1. There's then still code there which isn't reachable, and >> which a scanner will spot and report. >> >> Jan > > It's not clear to me whether you dislike the patch itself or the commit > message. If it's the latter, how about: > "ASSERT_UNREACHABLE() is used as a marker for intentionally > unreachable code, which > constitutes a motivated deviation from Rule 2.1. Additionally, in > non-release > builds, this macro performs a failing assertion to detect errors." Any feedback on this (with one edit: s/a failing assertion/an assertion/) -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com)