Re: Refactor compile-time assertion checks for C/C++ - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Refactor compile-time assertion checks for C/C++
Date
Msg-id 19674.1583987601@sss.pgh.pa.us
Whole thread Raw
In response to Re: Refactor compile-time assertion checks for C/C++  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Refactor compile-time assertion checks for C/C++
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> Indeed the bot is happy now.  By looking at the patch, one would note
> that what it just does is unifying the fallback "hack-ish"
> implementations so as C and C++ use the same thing, which is the
> fallback implementation for C of HEAD.  I would prefer hear first from
> more people to see if they like this change.  Or not.

I looked at this and tried it on an old (non HAVE__STATIC_ASSERT)
gcc version.  Seems to work, but I have a couple cosmetic suggestions:

1. The comment block above this was never updated to mention that
we're now catering for C++ too.  Maybe something like

  * gcc 4.6 and up supports _Static_assert(), but there are bizarre syntactic
  * placement restrictions.  Macros StaticAssertStmt() and StaticAssertExpr()
  * make it safe to use as a statement or in an expression, respectively.
  * The macro StaticAssertDecl() is suitable for use at file scope (outside of
  * any function).
  *
+ * On recent C++ compilers, we can use standard static_assert().
+ *
  * Otherwise we fall back on a kluge that assumes the compiler will complain
  * about a negative width for a struct bit-field.  This will not include a
  * helpful error message, but it beats not getting an error at all.


2. I think you could simplify the #elif to just

#elif defined(__cplusplus) && __cpp_static_assert >= 200410

Per the C standard, an unrecognized identifier in an #if condition
is replaced by zero.  So the condition will come out false as desired
if __cpp_static_assert isn't defined; you don't need to test that
separately.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Adé
Date:
Subject: Re: [PATCH] Fix for slow GIN index queries when "gin_fuzzy_search_limit"setting is relatively small for large tables
Next
From: Michael Paquier
Date:
Subject: Re: [Patch] pg_rewind: options to use restore_command fromrecovery.conf or command line