Re: [PATCH] Introduce hardbool attribute for C

[Alexandre Oliva <oliva@adacore.com>]

On Jul  8, 2022, Richard Biener <richard.guenther@gmail.com> wrote:

> The documentation should probably be explicit about this case.

Please consider, for purposes of review, the following incremental
patchlet as if integrated with yesterday's submission.

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index a63a94158341a..a1dcd581dd8ad 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -8483,7 +8483,22 @@ followed by a mapping from @code{false} and @code{true} to
 typedef char __attribute__ ((__hardbool__ (0x5a))) hbool;
 hbool first = 0;       /* False, stored as (char)0x5a.  */
 hbool second = !first; /* True, stored as ~(char)0x5a.  */
-@end smallexample
+
+static hbool zeroinit; /* False, stored as (char)0x5a.  */
+auto hbool uninit;     /* Undefined, may trap.  */
+@end smallexample
+
+When zero-initializing a variable or field of hardened boolean type
+(presumably held in static storage) the implied zero initializer gets
+converted to @code{_Bool}, and then to the hardened boolean type, so
+that the initial value is the hardened representation for @code{false}.
+Using that value is well defined.  This is @emph{not} the case when
+variables and fields of such types are uninitialized (presumably held in
+automatic or dynamic storage): their values are indeterminate, and using
+them invokes undefined behavior.  Using them may trap or not, depending
+on the bits held in the storage (re)used for the variable, if any, and
+on optimizations the compiler may perform on the grounds that using
+uninitialized values invokes undefined behavior.
 
 
 @item may_alias


-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>