RE: Proposal: Add more compile-time asserts to expose inconsistencies.
Smith, Peter <peters@fast.au.fujitsu.com>
From: "Smith, Peter" <peters@fast.au.fujitsu.com>
To: Andres Freund <andres@anarazel.de>, Michael Paquier <michael@paquier.xyz>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, "peter.eisentraut@2ndquadrant.com" <peter.eisentraut@2ndquadrant.com>, "tgl@sss.pgh.pa.us" <tgl@sss.pgh.pa.us>, "ilmari@ilmari.org" <ilmari@ilmari.org>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2019-12-05T00:51:18Z
Lists: pgsql-hackers
-----Original Message-----
From: Andres Freund <andres@anarazel.de> Sent: Tuesday, 3 December 2019 2:56 AM
> +StaticAssertDecl(lengthof(LockTagTypeNames) == (LOCKTAG_ADVISORY + 1),
> + "LockTagTypeNames array inconsistency");
> +
>
>These error messages strike me as somewhat unhelpful. I'd probably just reword them as "array length mismatch" or something like that.
OK. I have no problem to modify all my current assertion messages to your suggested text ("array length mismatch") if you think it is better.
Please correct me if I am wrong, but I didn't think the error message text is of very great significance here because it is a compile-time issue meaning the *only* person who would see the message is the 1 developer who accidentally introduced a bug just moments beforehand. The compile will fail with a source line number, and when the developer sees the StaticAssertDecl at that source line the cause of the error is anyway self-evident by the condition parameter.
Kind Regards
--
Peter Smith
Fujitsu Australia
Commits
-
Add declaration-level assertions for compile-time checks
- f1f10a1ba9e1 13.0 landed
-
Add support for static assertions in C++
- a2c8e5cfdb9d 11.0 cited