Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v16AP-004Xnf-33 for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Sep 2025 16:47:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1v16AN-00716i-Mz for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Sep 2025 16:46:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v16AN-00716a-DQ for pgsql-hackers@lists.postgresql.org; Tue, 23 Sep 2025 16:46:59 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1v16AJ-002POT-16 for pgsql-hackers@lists.postgresql.org; Tue, 23 Sep 2025 16:46:59 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 58NGknU13097371; Tue, 23 Sep 2025 12:46:52 -0400 From: Tom Lane To: Michael Paquier cc: Greg Burd , PostgreSQL Hackers , Robert Haas , Nathan Bossart , Masahiko Sawada Subject: Re: [PATCH] Add tests for Bitmapset In-reply-to: References: <3027069.1758606227@sss.pgh.pa.us> Comments: In-reply-to Michael Paquier message dated "Tue, 23 Sep 2025 20:07:13 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3097369.1758646009.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Sep 2025 12:46:49 -0400 Message-ID: <3097370.1758646009@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Michael Paquier writes: > On Tue, Sep 23, 2025 at 01:43:47AM -0400, Tom Lane wrote: >> This patch seems to be rather full of arbitrary casts to or >> from Datum, which is no longer okay. You need to be using >> the appropriate conversion macros, such as PointerGetDatum. > Right, this can ve reproduced with a -m32 added to gcc. Curiously, I don't see these warnings on 32-bit FreeBSD (with clang version 19.1.7). But I tested your patch on mamba's host and confirmed that it makes that gcc happy. > I don't see a need for a Datum manipulation in these conversion > macros, as we already allocate the results to and from "text" > before/after using the GETARG or RETURN macros. Using directly > text_to_cstring() and cstring_to_text() takes care of the warnings, as > well. Yeah, this is better, but I think the new macros could use a bit more parenthesis-twiddling: +#define BITMAPSET_TO_TEXT(bms) cstring_to_text(nodeToString((bms))) The extra parens around "bms" are surely unnecessary. (If they were necessary, it could only be because nodeToString was a macro that failed to parenthesize its argument where needed. But that would be a bug to fix in nodeToString, not here.) +#define TEXT_TO_BITMAPSET(str) (Bitmapset *) stringToNode(text_to_cstring= (str)) = Here, on the other hand, I think an extra outer set of parens would be a good idea, ie +#define TEXT_TO_BITMAPSET(str) ((Bitmapset *) stringToNode(text_to_cstrin= g(str))) It may be that the C cast binds tightly enough that this cannot be a problem, but I don't think assuming that is project style. regards, tom lane