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 CF057CDB474 for ; Tue, 17 Oct 2023 08:54:51 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.618145.961438 (Exim 4.92) (envelope-from ) id 1qsfqR-0007jG-KO; Tue, 17 Oct 2023 08:54:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 618145.961438; Tue, 17 Oct 2023 08:54:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qsfqR-0007j9-GZ; Tue, 17 Oct 2023 08:54:31 +0000 Received: by outflank-mailman (input) for mailman id 618145; Tue, 17 Oct 2023 08:54:30 +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 1qsfqQ-0007j3-Mr for xen-devel@lists.xenproject.org; Tue, 17 Oct 2023 08:54:30 +0000 Received: from support.bugseng.com (mail.bugseng.com [162.55.131.47]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c7b10304-6cca-11ee-9b0e-b553b5be7939; Tue, 17 Oct 2023 10:54:28 +0200 (CEST) Received: from support.bugseng.com (support.bugseng.com [162.55.131.47]) by support.bugseng.com (Postfix) with ESMTPA id 1CE9A4EE0737; Tue, 17 Oct 2023 10:54:28 +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: c7b10304-6cca-11ee-9b0e-b553b5be7939 MIME-Version: 1.0 Date: Tue, 17 Oct 2023 10:54:28 +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, andrew.cooper3@citrix.com, roger.pau@citrix.com, George Dunlap , Julien Grall , Wei Liu , Paul Durrant , xen-devel@lists.xenproject.org Subject: Re: [XEN PATCH][for-4.19 v2 7/8] xen/types: address Rule 10.1 for DECLARE_BITMAP use In-Reply-To: <8c0a4331-4a89-4cb2-02ed-70cad3ad2116@suse.com> References: <8c0a4331-4a89-4cb2-02ed-70cad3ad2116@suse.com> User-Agent: Roundcube Webmail/1.4.3 Message-ID: <89bd9f429c4a5e455956ca6be44da754@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 On 16/10/2023 17:49, Jan Beulich wrote: > On 12.10.2023 17:28, Nicola Vetrini wrote: >> --- a/xen/include/xen/types.h >> +++ b/xen/include/xen/types.h >> @@ -22,6 +22,14 @@ typedef signed long ssize_t; >> >> typedef __PTRDIFF_TYPE__ ptrdiff_t; >> >> +/* >> + * Users of this macro are expected to pass a positive value. > > Is passing 0 going to cause any issues? > I don't think so, even if that wouldn't make much sense. Given that the usage of the zero lenght array extension is documented, that shouldn't be a concern either. >> + * Eventually, this should become an unsigned quantity, but this >> + * requires fixing various uses of this macro and BITS_PER_LONG in >> signed >> + * contexts, such as type-safe 'min' macro uses, which give rise to >> build errors >> + * when the arguments have differing signedness, due to the build >> flags used. >> + */ > > I'm not convinced of the usefulness of this part of the comment. > > Jan > Isn't it useful to record why it was left as-is, and what should be done about it? If it's not, this can be dropped on commit, in my opinion. -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com)