RE: Proposal: Add more compile-time asserts to expose inconsistencies.

From: Andres Freund <andres(at)anarazel(dot)de> Sent: Wednesday, 13 November 2019 6:01 AM

>Peter Smith:
>
> Is there a reason to not just make StaticAssertExpr and StaticAssertStmt be the same? I don't want to proliferate variants that users have to understand if there's no compelling
> need. Nor do I think do we really need two different fallback implementation for static asserts.

>
> As far as I can tell we should be able to use the prototype based approach in all the cases where we currently use the "negative bit-field width" approach?

I also thought that the new "prototype negative array-dimension" based approach (i.e. StaticAssertDecl) looked like an improvement over the existing "negative bit-field width" approach (i.e. StaticAssertStmt), because it seems to work for more scenarios (e.g. file scope).

But I did not refactor existing code to use the new way because I was fearful that there might be some subtle reason why the StaticAssertStmt was deliberately made that way (e.g. as do/while), and last thing I want to do was break working code.

> Should then also update
> * 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.

Kind Regards.
Peter Smith
---
Fujitsu Australia