On Jul 8, 2022, Richard Biener <richard.guent...@gmail.com> wrote: > Does this follow some other compilers / language?
It is analogous to Ada's booleans with representation clauses and runtime validation checking at use points. > Is such feature used in existing code? Not that I know. The attribute name was my choice. That said, we have already delivered the experimental implementation to the customer who requested it (GCC was in stage3, thus the delayed submission), so by now they may already have some code using it. > Why is it useful to allow arbitrary values for true/false? Increasing the hamming distance between legitimate values is desirable to catch hardware-based attacks, but booleans are probably the only builtin type that has room for that. > Why is the default 0 and ~0 rather than 0 and 1 as for _Bool? My understanding is that the goal is to maximize the hamming distance between the legitimate values, so as to increase the sensibility to errors. There was no requirement for defaults to be these values, however. The examples often used 0x5a and 0xa5, but those seemed too arbitrary to be defaults. I found ~1 and 1 to be too nasty, so I went for 0 and ~0, that are still recognizable as false and true values, respectively, though I'm not sure whether this is advantageous. >> +@smallexample >> +typedef char __attribute__ ((__hardbool__ (0x5a))) hbool; >> +hbool first = 0; /* False, stored as (char)0x5a. */ >> +hbool second = !first; /* True, stored as ~(char)0x5a. */ > hbool thrid; > what's the initial value of 'third'? If it's an automatic variable, it's uninitialized, as expected for C. It might by chance happen to hold one of the legitimate values, but odds are it doesn't, and if so, accessing it will trap. If it's a static-storage variable, it will be zero-initialized as expected, but the zero will be mapped to the representation for false. > The documentation should probably be explicit about this case. Agreed, thanks, will do. > If the underlying representation is an Enum, why not have > hardened_enum instead? In Ada, Booleans are enumerator types with various conventions and builtin operations, with or without a representation clause, that sets the representation values for the enumerators. Other enumerations aren't subject to such conventions as automatic conversions between Boolean types with different representations, that enable all of them to be used interchangeably (source-wise) in logical expressions. It would nevertheless be feasible to implement hardened enumerator types, that, like Ada, perform runtime validation checking that the stored value corresponds to one of the enumerators. This would not fit some common use cases of enumerator types, e.g. those in which enumerators define bits or masks, and different enumerators are combined into a single variable. This was not the feature that we were asked to implement, though. > A hardened _Bool might want to have a special NaT value as well I > guess? That might sound appealing, but ISTM that it would instead break the symmetry of the maximal hamming distance between the representation values for true and false. OTOH, NaB, if so desired, would be just any other value; the challenge would be to get such a value stored in a variable, given that actual booleans can only hold true (nonzero) or false (zero), and neither would convert to NaB. -- 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>
