RE: Proposal: Add more compile-time asserts to exposeinconsistencies.

From: Andres Freund <andres@anarazel.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
variantsthat 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
improvementover the existing "negative bit-field width" approach (i.e. StaticAssertStmt), because it seems to work for
morescenarios (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
whythe StaticAssertStmt was deliberately made that way (e.g. as do/while), and last thing I want to do was break
workingcode. 

> 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