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 64D69C04FE1 for ; Wed, 16 Aug 2023 13:43:46 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.584776.915594 (Exim 4.92) (envelope-from ) id 1qWGoB-0000hq-78; Wed, 16 Aug 2023 13:43:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 584776.915594; Wed, 16 Aug 2023 13:43:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qWGoB-0000hj-4L; Wed, 16 Aug 2023 13:43:35 +0000 Received: by outflank-mailman (input) for mailman id 584776; Wed, 16 Aug 2023 13:43:33 +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 1qWGo9-0000hd-RX for xen-devel@lists.xenproject.org; Wed, 16 Aug 2023 13:43:33 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e3d3a1a1-3c3a-11ee-8779-cb3800f73035; Wed, 16 Aug 2023 15:43:32 +0200 (CEST) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id 05EB44EE0737; Wed, 16 Aug 2023 15:43:32 +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: e3d3a1a1-3c3a-11ee-8779-cb3800f73035 MIME-Version: 1.0 Date: Wed, 16 Aug 2023 15:43:31 +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> <6e1dbf093687e5fa66295621ce67e4dc@bugseng.com> <2b26baf0-6a82-0bff-99b5-ade067e0d74d@suse.com> User-Agent: Roundcube Webmail/1.4.3 Message-ID: <25f65f8cf633d72dc2f829fa9cd74f08@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 On 16/08/2023 13:23, Jan Beulich wrote: > On 16.08.2023 12:47, Nicola Vetrini wrote: >> On 16/08/2023 12:31, Jan Beulich wrote: >>> On 16.08.2023 12:01, Nicola Vetrini wrote: >>>> 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. >>>>> >>>>> 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/) >>> >>> The patch here is kind of okay, but I'm afraid I view my earlier >>> question >>> as not addressed: How will the proposed change prevent the scanner >>> from >>> spotting issues here in release builds? Just stating in the >>> description >>> that there's a deviation is not going to help that. >> >> There is a deviation already in place. At the moment it just ignores >> anything below an unreachable ASSERT_UNREACHABLE(), no matter what >> that >> macro will expand to. > > What do you mean by "in place"? docs/misra/ has nothing, afaics. And > automation/eclair_analysis/ECLAIR/deviations.ecl is merely filtering > things out of reports, aiui. (Plus of course there should be a single > central place where all deviations are recorded, imo.) The second statement is not quite correct, as some of the configurations instruct the checker how to behave. -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com)