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 09BDBC0219D for ; Thu, 13 Feb 2025 15:32:49 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.887811.1297258 (Exim 4.92) (envelope-from ) id 1tibCU-0007Mm-6J; Thu, 13 Feb 2025 15:32:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 887811.1297258; Thu, 13 Feb 2025 15:32:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tibCU-0007Mf-3J; Thu, 13 Feb 2025 15:32:26 +0000 Received: by outflank-mailman (input) for mailman id 887811; Thu, 13 Feb 2025 15:32:24 +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 1tibCS-0007MZ-GX for xen-devel@lists.xenproject.org; Thu, 13 Feb 2025 15:32:24 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b830710e-ea1f-11ef-88c1-8ba37f82fa57; Thu, 13 Feb 2025 16:32:22 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id D4A464EF40C8; Thu, 13 Feb 2025 16:32:21 +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: b830710e-ea1f-11ef-88c1-8ba37f82fa57 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bugseng.com; s=mail; t=1739460742; bh=g/RCIobIcOAtpyhrU2Z/MfFJTDXgw3oZvhDDMiM6Vfs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=B4zIJ2p3Sl8MqqyG6YGlC4YwyPenbZsnvvAHnc3ZE3l+ALZfR1Q8/33H7Af1U57Nx hziQ92omvDV2ZrAhz+ht9vgt1LbVvhlRyjgXD/VVafQCQXwqpXV+LwSz01InJQHRSd sy+UilevzaGEVYBFgTRfQHFMQqNUCT8i52BrcabTRHKVaV8Te0TyH+atfpNheJDE7n 7djIp4o2aVDC5PFe0PD6W80GacaxXp8HSPlL6+Wf8pn4Y3G1pvtROlpTadYCjvmaDm IkRhyHHUNXXugt7vZS1uAFeDfA0rMSW+vSyM/kwXXbO7Ugfo2gxRso1e8doJl/U7s7 //xXjZ8KBOWFQ== MIME-Version: 1.0 Date: Thu, 13 Feb 2025 16:32:21 +0100 From: Nicola Vetrini To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie Subject: Re: [PATCH] radix-tree: don't left-shift negative values In-Reply-To: <2118904d-3a33-47f3-af68-7303bc17186c@suse.com> References: <70ebba90-59a8-4224-b67c-b9eb373684b4@suse.com> <0de3a7e8c55af172e7260f8bb22949b4@bugseng.com> <2118904d-3a33-47f3-af68-7303bc17186c@suse.com> 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 2025-02-13 16:01, Jan Beulich wrote: > On 13.02.2025 15:52, Nicola Vetrini wrote: >> On 2025-02-13 15:22, Jan Beulich wrote: >>> Any (signed) integer is okay to pass into radix_tree_int_to_ptr(), >>> yet >>> left shifting negative values is UB. Use an unsigned intermediate >>> type, >>> reducing the impact to implementation defined behavior (for the >>> unsigned->signed conversion). >>> >>> Also please Misra C:2012 rule 7.3 by dropping the lower case numeric >>> 'l' >>> tag. >>> >>> No difference in generated code, at least on x86. >>> >>> Fixes: b004883e29bb ("Simplify and build-fix (for some gcc versions) >>> radix_tree_int_to_ptr()") >>> Reported-by: Teddy Astie >>> Signed-off-by: Jan Beulich >>> --- >>> Bugseng: Why was the 7.3 violation not spotted by Eclair? According >>> to >>> tagging.ecl the codebase is clean for this rule, aiui. >>> >> >> radix-tree.{c,h} is out of scope: >> >> automation/eclair_analysis/ECLAIR/out_of_scope.ecl:32:-file_tag+={out_of_scope,"^xen/include/xen/radix-tree\\.h$"} >> docs/misra/exclude-list.json:153: "rel_path": >> "common/radix-tree.c", > > Is there a record of why they are excluded? Is it further explainable > why exclude-list.json mentions only the .c file and out_of_scope.ecl > mentions only the .h one? Shouldn't different parts be in sync? > exclude-list.json is used to generate a configuration file for ECLAIR just before the analysis starts, so effectively both are excluded. It's a good point however to have only one file to handle exclusions, and use that file to generate the exclusion list dynamically, but then someone might want to exclude certain files only in some analyses and not others, which is not a good fit for exclude-list.json as it is now. @Stefano, thoughts? Thanks, Nicola >> We are in the process of setting up a wider analysis (i.e. with a >> different exclusion set) with a broader configuration that may catch >> these issues. > > Good. > > Jan -- Nicola Vetrini, B.Sc. Software Engineer BUGSENG (https://bugseng.com) LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253