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
signature.asc
Description: PGP signature