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 A2AD6C54E58 for ; Mon, 25 Mar 2024 14:48:11 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.697770.1088854 (Exim 4.92) (envelope-from ) id 1rolcD-0006L9-Tr; Mon, 25 Mar 2024 14:47:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 697770.1088854; Mon, 25 Mar 2024 14:47:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rolcD-0006L2-Q0; Mon, 25 Mar 2024 14:47:57 +0000 Received: by outflank-mailman (input) for mailman id 697770; Mon, 25 Mar 2024 14:47:56 +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 1rolcC-0006Kw-0Z for xen-devel@lists.xenproject.org; Mon, 25 Mar 2024 14:47:56 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a85cb61f-eab6-11ee-a1ef-f123f15fe8a2; Mon, 25 Mar 2024 15:47:52 +0100 (CET) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id 0CD1B4EE0739; Mon, 25 Mar 2024 15:47:52 +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: a85cb61f-eab6-11ee-a1ef-f123f15fe8a2 MIME-Version: 1.0 Date: Mon, 25 Mar 2024 15:47:52 +0100 From: Nicola Vetrini To: Jan Beulich Cc: sstabellini@kernel.org, michal.orzel@amd.com, xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com, consulting@bugseng.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, bertrand.marquis@arm.com, julien@xen.org, xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH 08/11] x86/altcall: address violations of MISRA C Rule 20.7 In-Reply-To: <072aa89b-2a03-4823-af72-28a2a882b373@suse.com> References: <653ead65966226f50b0e4ae0268912c9710f9dba.1711118582.git.nicola.vetrini@bugseng.com> <072aa89b-2a03-4823-af72-28a2a882b373@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 2024-03-25 10:38, Jan Beulich wrote: > On 22.03.2024 17:01, Nicola Vetrini wrote: >> MISRA C Rule 20.7 states: "Expressions resulting from the expansion >> of macro parameters shall be enclosed in parentheses". Therefore, some >> macro definitions should gain additional parentheses to ensure that >> all >> current and future users will be safe with respect to expansions that >> can possibly alter the semantics of the passed-in macro parameter. >> >> No functional change. >> >> Signed-off-by: Nicola Vetrini > > Hmm. These macros are, at least in part, hard to read already. The > added > parentheses, while necessary when following the rule to the letter, are > making things worse, even if just slightly. I therefore have a proposal > / > question: > >> --- a/xen/arch/x86/include/asm/alternative.h >> +++ b/xen/arch/x86/include/asm/alternative.h >> @@ -243,28 +243,28 @@ extern void alternative_branches(void); >> >> #define alternative_vcall0(func) ({ \ >> ALT_CALL_NO_ARG1; \ >> - (void)sizeof(func()); \ >> + (void)sizeof((func)()); \ > > Like this, all that's touched here are (syntactical, but not real) > function > invocations. Function calls, like all postfix operators, are highest > precedence. Hence by omitting parentheses in that case no breakage can > happen as a result: If the passed expression is another postfix one, > that'll > be evaluated first anyway. If any other expression is passed (aside > primary > ones, of course), that'll be evaluated afterwards only due to being > lower > precedence, irrespective of the presence/absence of parentheses. > > Therefore, where harmful to readability, can we perhaps leave postfix > expressions alone? > > Jan While I can understand the benefits of this, and the reasoning on postfix expressions, what about, for instance (modulo the actual invocation, this is just an example) alternative_vcall0(2 + f) or similar scenarios? -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com)