Re: Refactor compile-time assertion checks for C/C++ - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Refactor compile-time assertion checks for C/C++
Date
Msg-id 20200316053240.GC2331@paquier.xyz
Whole thread Raw
In response to Re: Refactor compile-time assertion checks for C/C++  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Refactor compile-time assertion checks for C/C++  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Mar 13, 2020 at 11:00:33AM -0400, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> Hmm.  v3 actually broke the C++ fallback of StaticAssertExpr() and
>> StaticAssertStmt() (v1 did not), a simple fix being something like
>> the attached.
>
> The buildfarm seems happy, so why do you think it's broken?

Extensions like the attached don't appreciate it, and we have nothing
like that in core.  Perhaps we could, but it is not really appealing
for all platforms willing to run the tests to require CXX or such..

> If we do need to change it, I'd be inclined to just use the do{}
> block everywhere, not bothering with the extra #if test.

Not sure what you mean here because we cannot use the do{} flavor
either for the C fallback, no?  See for example the definitions of
unconstify() in c.h.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
Next
From: Justin Pryzby
Date:
Subject: Re: Expose lock group leader pid in pg_stat_activity