Обсуждение: Confused static assertion implementation

Hi,

I won't be surprised if Peter (CC'd) already has a patch for this in
his C11 incubation branch, but if not, maybe this will be useful.

While experimenting with threads and atomics on various systems, I
didn't like the way our macros failed in the ancient fallback code on
Visual Studio.  That only seems to be necessary for
StaticAssertExpr(), the rarest case.  That led to some observations:

* the meson script defines HAVE__STATIC_ASSERT if you have GCC
statement expressions, so why not just say so with
HAVE_STATEMENT_EXPRESSIONS, and keep ye olde fallback only for
StaticAssertExpr()?

* the configure script is different, tautological and wrong for
(evidently hypothetical) non-GCC-compatible C11 compiler given the
above interpretation of the macro

* to my knowledge we haven't written down which C++ standard our
headers conform to anywhere, but it surely can't be older than C++11
(I could elaborate), so I don't think we need the two __cplusplus
implementations

Here's an attempt to tidy that up.

We could also consider allowing ourselves to use standard
static_assert() directly in new code, in scopes that accept
declarations (eg file top-level, inside structs, inside functions as
allowed by our self-imposed -Wno-declaration-after-statement rule),
but that's essentially an independent question and I can also see that
the inconsistency might be annoying, cf size_t/Size, uint64_t/uint64,
etc debates with different outcomes.  For reference, we currently have
84 "...Decl", 10 "...Expr", and 18 "...Stmt" occurrences in the tree,
and if that has any predictive power, the vast majority of new code
would likely just use static_assert().

. o O { I wonder if it's possible to write a C23/C++17-compatible
single-argument static_assert() macro, or if you'd get stuck in a loop
and need to use a different name... the message argument is so often
boring/redundant... }

> On Nov 14, 2025, at 10:13, Thomas Munro <thomas.munro@gmail.com> wrote:
>
> Hi,
>
> I won't be surprised if Peter (CC'd) already has a patch for this in
> his C11 incubation branch, but if not, maybe this will be useful.
>
> While experimenting with threads and atomics on various systems, I
> didn't like the way our macros failed in the ancient fallback code on
> Visual Studio.  That only seems to be necessary for
> StaticAssertExpr(), the rarest case.  That led to some observations:
>
> * the meson script defines HAVE__STATIC_ASSERT if you have GCC
> statement expressions, so why not just say so with
> HAVE_STATEMENT_EXPRESSIONS, and keep ye olde fallback only for
> StaticAssertExpr()?
>

+1, I think this is clearer.

>
> . o O { I wonder if it's possible to write a C23/C++17-compatible
> single-argument static_assert() macro, or if you'd get stuck in a loop
> and need to use a different name... the message argument is so often
> boring/redundant... }
> <0001-Refactor-static_assert-support.patch>

A few small comments:

1
```
 main ()
 {
-({ _Static_assert(1, "foo"); })
+({ _Static_assert(1, "foo"); });
+
   ;
   return 0;
 }
```

As you added a semi-colon in the line, the one after the empty line can be deleted, though C allows empty statement,
butunnecessary, and may lead to confusion for code readers. 

2
```
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv__static_assert" >&5
-$as_echo "$pgac_cv__static_assert" >&6; }
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv__statement_expressions" >&5
+$as_echo "$pgac_cv__statement_expressions" >&6; }
 if test x"$pgac_cv__static_assert" = xyes ; then
```

You missed to replace this pgac_cv__static_assert with the new name.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

On Fri, Nov 14, 2025 at 6:18 PM Chao Li <li.evan.chao@gmail.com> wrote:
> As you added a semi-colon in the line, the one after the empty line can be deleted, though C allows empty statement,
butunnecessary, and may lead to confusion for code readers. 

> You missed to replace this pgac_cv__static_assert with the new name.

Ugh, yeah, the configure change was hopeless.  It looked like it
worked in configure's stdout, which I mistook for success and posted
too soon, sorry about that.  I have fixed those points and verified
that pg_config.h actually has the expected value.

Thanks for the review!