Re: Refactor compile-time assertion checks for C/C++

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Georgios Kokolatos <gkokolatos(at)pm(dot)me>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Refactor compile-time assertion checks for C/C++
Date: 2020-03-16 05:32:40
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Fri, Mar 13, 2020 at 11:00:33AM -0400, Tom Lane wrote:
> Michael Paquier <michael(at)paquier(dot)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.

Attachment Content-Type Size
blackhole_cplusplus.tar.gz application/gzip 1.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2020-03-16 05:43:41 Re: Expose lock group leader pid in pg_stat_activity
Previous Message Dilip Kumar 2020-03-16 05:13:35 Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager