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 332C4C10F16 for ; Tue, 30 Apr 2024 15:25:18 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.715009.1116435 (Exim 4.92) (envelope-from ) id 1s1pLq-0004Q0-MQ; Tue, 30 Apr 2024 15:25:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 715009.1116435; Tue, 30 Apr 2024 15:25:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1s1pLq-0004Pt-IU; Tue, 30 Apr 2024 15:25:02 +0000 Received: by outflank-mailman (input) for mailman id 715009; Tue, 30 Apr 2024 15:25:01 +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 1s1pLp-0004PS-PS for xen-devel@lists.xenproject.org; Tue, 30 Apr 2024 15:25:01 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cf4a3210-0705-11ef-909b-e314d9c70b13; Tue, 30 Apr 2024 17:25:00 +0200 (CEST) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id 1A7F64EE0738; Tue, 30 Apr 2024 17:25:00 +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: cf4a3210-0705-11ef-909b-e314d9c70b13 MIME-Version: 1.0 Date: Tue, 30 Apr 2024 17:25:00 +0200 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, bertrand.marquis@arm.com, julien@xen.org, Anthony PERARD , Andrew Cooper , George Dunlap , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH v2 2/3] xen/unaligned: address violation of MISRA C Rule 20.7 In-Reply-To: References: 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-04-30 17:13, Jan Beulich wrote: > On 30.04.2024 16:28, 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 >> --- >> Somewhat surprisingly, the change in the tools directory is also >> needed, otherwise >> some CI build jobs fail (see e.g. [1]). This is not undefined >> behaviour >> as long as the two definitions are kept in sync, following section >> 6.10.3p2 of the C99 standard, but having the definition in >> common-macros.h >> is still a potential problem. >> >> [1] >> https://gitlab.com/xen-project/people/bugseng/xen/-/jobs/6742878558 > > This is pretty absurd, and the use of the Xen header in > xg_dom_decompress_unsafe_zstd.c should probably have gone away with the > introduction of the unaligned macros into ... > I agree. I assumed it was known/deliberate. >> --- a/tools/include/xen-tools/common-macros.h >> +++ b/tools/include/xen-tools/common-macros.h >> @@ -102,7 +102,7 @@ >> >> #define put_unaligned_t(type, val, ptr) do { \ >> struct { type x; } __packed *ptr_ = (typeof(ptr_))(ptr); \ >> - ptr_->x = val; \ >> + ptr_->x = (val); \ >> } while (0) >> >> #define get_unaligned(ptr) get_unaligned_t(typeof(*(ptr)), ptr) > > ... here. We simply cannot assume the two definitions can indefinitely > be kept in sync. > >> --- a/xen/include/xen/unaligned.h >> +++ b/xen/include/xen/unaligned.h >> @@ -19,7 +19,7 @@ >> >> #define put_unaligned_t(type, val, ptr) do { \ >> struct { type x; } __packed *ptr_ = (typeof(ptr_))(ptr); \ >> - ptr_->x = val; \ >> + ptr_->x = (val); \ > > Nit: One of the padding tabs then wants dropping. > > Jan -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com)