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 29F08C61D9B for ; Wed, 22 Nov 2023 09:28:20 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.638571.995263 (Exim 4.92) (envelope-from ) id 1r5jWa-0000Qn-A4; Wed, 22 Nov 2023 09:28:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 638571.995263; Wed, 22 Nov 2023 09:28:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1r5jWa-0000Qg-6P; Wed, 22 Nov 2023 09:28:00 +0000 Received: by outflank-mailman (input) for mailman id 638571; Wed, 22 Nov 2023 09:27:59 +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 1r5jWZ-0000Qa-E7 for xen-devel@lists.xenproject.org; Wed, 22 Nov 2023 09:27:59 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6c0a2aef-8919-11ee-98e1-6d05b1d4d9a1; Wed, 22 Nov 2023 10:27:57 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id 0BD754EE073C; Wed, 22 Nov 2023 10:27:57 +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: 6c0a2aef-8919-11ee-98e1-6d05b1d4d9a1 MIME-Version: 1.0 Date: Wed, 22 Nov 2023 10:27:57 +0100 From: Nicola Vetrini To: Jan Beulich Cc: Stefano Stabellini , Andrew Cooper , Xen Devel , Consulting , George Dunlap , Wei Liu , Roger Pau , Bertrand Marquis , Michal Orzel , Julien Grall Subject: Re: Devise macros to encapsulate (x & -x) In-Reply-To: <1799e5c8-ab8a-453f-96f0-c3b66ae446e1@suse.com> References: <08e6cb27d65250d109df0ef8a49dc80a@bugseng.com> <1799e5c8-ab8a-453f-96f0-c3b66ae446e1@suse.com> Message-ID: <054ccbe1173f4a9ec27ca4201e6d74a2@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 >> >> Jan, would you be willing to accept that other maintainers have a >> preference for having a single MACRO even if suboptimal? > > I can live with that, even if I'm surprised by this perspective that > others > take. How can we, in reviews, tell people to make sure arguments are > evaluated only once, when then we deliberately do otherwise in a case > like > the one here? The criteria of "not likely to be used in cases that have > side effects" is an extremely fuzzy and sufficiently weak one, imo. I > for > one am even worried about the uses in MASK_EXTR() / MASK_INSR(), and > would > have considered introducing single-evaluation forms there as well. > >> If so, can we go ahead and commit the original patches? > > Well, the renaming needs to be done there anyway. > I can do the renaming if you don't feel particularly safe doing it on commit. I already modified my local version to do experiments with single evaluation anyway. -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com)