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

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: "Smith, Peter" <peters@fast.au.fujitsu.com>
Cc: Peter Eisentraut <peter_e@gmx.net>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-11-14T18:07:35Z
Lists: pgsql-hackers
Hi,

On 2019-11-13 03:23:06 +0000, Smith, Peter wrote:
> 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 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.

That'll just leave us with cruft. And it's not like this stuff will
break in a subtle way or such....

Greetings,

Andres Freund



Commits

  1. Add declaration-level assertions for compile-time checks

  2. Add support for static assertions in C++