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 E9E60C197A0 for ; Fri, 17 Nov 2023 11:15:57 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.635063.990784 (Exim 4.92) (envelope-from ) id 1r3wp4-00051q-Bp; Fri, 17 Nov 2023 11:15:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 635063.990784; Fri, 17 Nov 2023 11:15:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1r3wp4-00051j-93; Fri, 17 Nov 2023 11:15:42 +0000 Received: by outflank-mailman (input) for mailman id 635063; Fri, 17 Nov 2023 11:15:41 +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 1r3wp3-00051d-CJ for xen-devel@lists.xenproject.org; Fri, 17 Nov 2023 11:15:41 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a372c2d1-853a-11ee-9b0e-b553b5be7939; Fri, 17 Nov 2023 12:15:39 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id A88A94EE0744; Fri, 17 Nov 2023 12:15:38 +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: a372c2d1-853a-11ee-9b0e-b553b5be7939 MIME-Version: 1.0 Date: Fri, 17 Nov 2023 12:15:38 +0100 From: Nicola Vetrini To: Andrew Cooper Cc: Xen Devel , Consulting , Stefano Stabellini , Jbeulich , George Dunlap , Julien Grall , Wei Liu , Roger Pau , Bertrand Marquis , Michal Orzel Subject: Re: Devise macros to encapsulate (x & -x) In-Reply-To: References: <08e6cb27d65250d109df0ef8a49dc80a@bugseng.com> Message-ID: <7f4563916d287a461c7ae0378d97ecb0@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 2023-11-17 12:04, Andrew Cooper wrote: > On 17/11/2023 10:17 am, Nicola Vetrini wrote: >> Hi all, >> >> As discussed in this thread [1], which is about complying with MISRA C >> Rule 10.1, >> a macro was introduced to encapsulate a well-known construct: >> >> /* >>  * Given an unsigned integer argument, expands to a mask where just >> the least >>  * significant nonzero bit of the argument is set, or 0 if no bits are >> set. >>  */ >> #define ISOLATE_LSB(x) ((x) & -(x)) >> >> This macro has a gained some calls in the subsequent patches in that >> thread, but concerns were raised around the fact that it would be >> better to devise a macro that evaluates its argument only once. A >> proposed solution is this (thanks to Jan Beulich): >> >> #define ISOLATE_LSB(x) ({ \ >>      typeof(x) x_ = (x); \ >>      x_ & -x_; \ >> }) > > Of course this was going to explode. > > This isn't even the first time an unwise attempt to do > single-evaluation > has needed to be reverted because it doesn't work with Integer Constant > Expressions. > > Switch it back to the first form.  It's obviously a macro to begin > with, > and not likely to be used in cases that have side effects. > > ~Andrew Actually no usages of either forms are yet committed, just the definition of the first form, so nothing needs to be reverted. I should have clarified that, sorry. If the other patches in the series go in unmodified (modulo renaming, but that's trivial), they would use the first form. -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com)