Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iP9Gj-0002qK-Hr for pgsql-hackers@arkaria.postgresql.org; Mon, 28 Oct 2019 17:57:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iP9Gi-0002qb-64 for pgsql-hackers@arkaria.postgresql.org; Mon, 28 Oct 2019 17:57:28 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iP9Gh-0002qU-Ta for pgsql-hackers@lists.postgresql.org; Mon, 28 Oct 2019 17:57:27 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iP9Gf-0007Zo-DB; Mon, 28 Oct 2019 17:57:27 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x9SHvJcu028365; Mon, 28 Oct 2019 13:57:19 -0400 From: Tom Lane To: Amit Kapila cc: PostgreSQL Hackers , Andrew Gierth , Michael Meskes Subject: Re: define bool in pgtypeslib_extern.h In-reply-to: References: <16583.1572010913@sss.pgh.pa.us> <18578.1572020755@sss.pgh.pa.us> <32373.1572110364@sss.pgh.pa.us> Comments: In-reply-to Amit Kapila message dated "Mon, 28 Oct 2019 11:30:14 +0530" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28363.1572285439.1@sss.pgh.pa.us> Date: Mon, 28 Oct 2019 13:57:19 -0400 Message-ID: <28364.1572285439@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Amit Kapila writes: > On Sat, Oct 26, 2019 at 10:49 PM Tom Lane wrote: >> I'm inclined to think that we need to make ecpglib.h's bool-related >> definitions exactly match c.h, which will mean that it has to pull in >> on most platforms, which will mean adding a control symbol >> for that to ecpg_config.h. I do not think we should export >> HAVE_STDBOOL_H and SIZEOF_BOOL there though; probably better to have >> configure make the choice and export something named like PG_USE_STDBOOL. > This sounds reasonable to me, but we also might want to do something > for probes.d. To be clear, I am not immediately planning to write a > patch for this. As far as probes.d goes, it seems to work to do @@ -20,7 +20,7 @@ #define BlockNumber unsigned int #define Oid unsigned int #define ForkNumber int -#define bool char +#define bool _Bool provider postgresql { although removing the macro altogether leads to compilation failures. I surmise that dtrace is trying to compile the generated code without any #include's, so that only compiler built-in types will do. (I tried this on macOS, FreeBSD, and NetBSD, to the extent of seeing whether a build with --enable-dtrace goes through. I don't know enough about dtrace to test the results easily, but I suppose that if it compiles then this is OK.) This would, of course, not work on any platform where we're not using , but I doubt that the set of platforms where dtrace works includes any such. A plausible alternative is to do -#define bool char +#define bool unsigned char which is correct on platforms where we don't use , and is at least no worse than now on those where we do. In practice, since we know sizeof(_Bool) == 1 on platforms where we use it, this is probably just fine for dtrace's purposes. Anyone have a preference? regards, tom lane