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
StaticAssertStmt().
--
Michael
