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 63AEFC001DF for ; Wed, 16 Aug 2023 10:48:05 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.584639.915484 (Exim 4.92) (envelope-from ) id 1qWE3r-0007fr-Ih; Wed, 16 Aug 2023 10:47:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 584639.915484; Wed, 16 Aug 2023 10:47: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 1qWE3r-0007fk-EX; Wed, 16 Aug 2023 10:47:35 +0000 Received: by outflank-mailman (input) for mailman id 584639; Wed, 16 Aug 2023 10:47:34 +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 1qWE3q-0007fb-3R for xen-devel@lists.xenproject.org; Wed, 16 Aug 2023 10:47:34 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4d39e916-3c22-11ee-9b0c-b553b5be7939; Wed, 16 Aug 2023 12:47:31 +0200 (CEST) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id 6D6F84EE0737; Wed, 16 Aug 2023 12:47:31 +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: 4d39e916-3c22-11ee-9b0c-b553b5be7939 MIME-Version: 1.0 Date: Wed, 16 Aug 2023 12:47: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: <2b26baf0-6a82-0bff-99b5-ade067e0d74d@suse.com> 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: 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 12:31, Jan Beulich wrote: > On 16.08.2023 12:01, Nicola Vetrini wrote: >> 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. >>> >>> 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. > > Jan 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. -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com)