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 53885CD68E8 for ; Tue, 10 Oct 2023 09:04:47 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.614623.955816 (Exim 4.92) (envelope-from ) id 1qq8fF-0007uJ-2M; Tue, 10 Oct 2023 09:04:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 614623.955816; Tue, 10 Oct 2023 09:04:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qq8fE-0007uC-VN; Tue, 10 Oct 2023 09:04:28 +0000 Received: by outflank-mailman (input) for mailman id 614623; Tue, 10 Oct 2023 09:04:28 +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 1qq8fE-0007u6-DW for xen-devel@lists.xenproject.org; Tue, 10 Oct 2023 09:04:28 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 03ae73b0-674c-11ee-98d3-6d05b1d4d9a1; Tue, 10 Oct 2023 11:04:27 +0200 (CEST) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id DC4B54EE0742; Tue, 10 Oct 2023 11:04:26 +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: 03ae73b0-674c-11ee-98d3-6d05b1d4d9a1 MIME-Version: 1.0 Date: Tue, 10 Oct 2023 11:04:26 +0200 From: Nicola Vetrini To: Luca Fancellu Cc: Stefano Stabellini , Julien Grall , Xen-devel , michal.orzel@amd.com, xenia.ragiadakou@amd.com, Ayan Kumar Halder , consulting@bugseng.com, Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Henry Wang , Simone Ballarin , Doug Goldstein , George Dunlap , Wei Liu , Andrew Cooper Subject: Re: [XEN PATCH] xen: Add SAF deviations for MISRA C:2012 Rule 7.1 In-Reply-To: <2AC05F6B-477A-45C3-A865-E0917692EE12@arm.com> References: <338d8e574db943a86c7605e4c6d9a299d45f067d.1696347345.git.nicola.vetrini@bugseng.com> <2894008e8f612296da84267346ae4240@bugseng.com> <9DD525D9-DB6D-4888-9266-FB45906A0E0F@arm.com> <1ceb5aa0-d374-4357-964f-1341468d542e@xen.org> <2AC05F6B-477A-45C3-A865-E0917692EE12@arm.com> User-Agent: Roundcube Webmail/1.4.3 Message-ID: <784666fd145d1bdcd2afc4607de12dd1@bugseng.com> X-Sender: nicola.vetrini@bugseng.com Organization: BUGSENG s.r.l. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 10/10/2023 09:29, Luca Fancellu wrote: >> >>>> /* SAF-x-safe */ >>>> if ( modrm_mod == MASK_EXTR(instr_modrm, 0300) && (modrm_reg & 7) == >>>> MASK_EXTR(instr_modrm, 0070) && (modrm_rm & 7) == >>>> MASK_EXTR(instr_modrm, >>>> 0007) ) >>>> >>>> Any other ideas? >>> >>> Could we have a number in the comment to indicate the number of lines >>> the >>> comment applies to? >> >> Luca can confirm that what I am about to write is correct; my >> understanding is that ECLAIR supports it, but cppcheck does not. Which >> means for cppcheck we would have to translate the SAF tag with >> xen_analyize to: >> >> /* cppcheck tag */ >> line1 >> /* cppcheck tag */ >> line2 >> /* cppcheck tag */ >> line3 >> >> and that would end up changing the line numbers in the source files so >> the cppcheck report wouldn't match with the original line numbers any >> longer > > Yes, but it’s not only Cppcheck, it’s also Coverity that supports only > the above notation. > > For Cppcheck we could do something, but for Coverity we can’t. > > Anyway, Stefano or Nicola, I would like to understand where Eclair > reports the violation > in the case of #define, does it report at the usage or at the > definition? > > Cheers, > Luca The report is at the usage site, but ECLAIR can be configured to deviate based on a comment at the macro definition, or also just the macro name for reports of that rule (e.g. Q[1-3]): #define M(a, b) (b) /* -E> safe MC3R1.R7.1 1 blabla */ #define Q1(s) M(s, 0300) /* -E> safe MC3R1.R7.1 1 blabla */ #define Q2(s) M(s, 0070) /* -E> safe MC3R1.R7.1 1 blabla */ #define Q3(s) M(s, 0007) void f(void) { int x = 1; int y = 2; if ( (x & 2) == Q1(y) && (x & 3) == Q2(y) && (x & 7) == Q3(y) ) { y = y + 1; } } -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com)