On Sat, Mar 21, 2020 at 07:22:41PM -0400, Tom Lane wrote:
> which of course is pointing at
>
> StaticAssertStmt(((int64) -1 >> 1) == (int64) -1,
> "arithmetic right shift is needed");
>
> so the existing "C and C++" fallback StaticAssertStmt doesn't work for
> older g++. (This is g++ 4.4.7 from RHEL6.)
Hmm. Thanks. I just have an access down to 7.5 on my machine.
> Huh? Surely do{} is a legal statement.
Yep, still my VS-2015 compiler complains when using the fallback with
do{} for statements, and I am not sure why. An extra choice coming to
my mind would be to use a more native MS implementation, as documented
here:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/assert-asserte-assert-expr-macros?view=vs-2019
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/static-assert-macro?view=vs-2019
This requires an extra branch in our implementation set which is not
really appealing, with I guess the following mapping (not tested):
- _STATIC_ASSERT for StaticAssertDecl and StaticAssertExpr.
- _ASSERT_EXPR for and StaticAssertStmt.
I think that one advantage is that this would allow to simplify the
fallback implementations for C/C++ to use do{}s.
> Maybe we should just revert b7f64c64d instead of putting more time
> into this. It's looking like we're going to end up with four or so
> implementations no matter what, so it's getting hard to see any
> real benefit.
Indeed. I have tried a couple of other things I could think of, but I
cannot really get down to 3 implementations, so there is no actual
benefit.
I have done a complete revert to keep the history cleaner for release
notes and such, including this part:
- * On recent C++ compilers, we can use standard static_assert().
Don't you think that we should keep this comment at the end? It is
still true.
Thanks for the discussion!
--
Michael