|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||"Smith, Peter" <peters(at)fast(dot)au(dot)fujitsu(dot)com>|
|Cc:||Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "peter(dot)eisentraut(at)2ndquadrant(dot)com" <peter(dot)eisentraut(at)2ndquadrant(dot)com>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "ilmari(at)ilmari(dot)org" <ilmari(at)ilmari(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Proposal: Add more compile-time asserts to expose inconsistencies.|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Wed, Nov 27, 2019 at 12:23:33PM +0000, Smith, Peter wrote:
> * That is beyond the scope for what I wanted my patch to achieve; my
> * use-cases are C code only.
Well, FWIW, I do have some extensions using __cplusplus and I am
pretty sure that I am not the only one with that. The thing is that
with your patch folks would not get any compilation failures *now*
because all the declarations of StaticAssertDecl() are added within
the .c files, but once a patch which includes a declaration in a
header, something very likely to happen, is merged then we head into
breaking suddenly the compilation of those modules. And that's not
nice. That's also a point raised by Andres upthread.
> I am happy if somebody else with more ability to test C++ properly
> wants to add the __cplusplus variant of the new macro.
In short, attached is an updated version of your patch which attempts
to solve that. I have tested this with some cplusplus stuff, and GCC
for both versions (static_assert is available in GCC >= 6, but a
manual change of c.h does the trick).
I have edited the patch a bit while on it, your assertions did not use
project-style grammar, the use of parenthesis was inconsistent (see
relpath.c for example), and pgindent has complained a bit.
Also, I am bumping the patch to next CF for now. Do others have
thoughts to share about this version? I would be actually fine to
commit that, even if the message generated for the fallback versions
is a bit crappy with a complain about a negative array size, but
that's not new to this patch as we use that as well with
|Next Message||Michael Paquier||2019-11-29 02:29:03||Re: [PATCH] ltree, lquery, and ltxtquery binary protocol support|
|Previous Messageemail@example.com||2019-11-29 01:44:39||RE: WAL archive is lost|