Re: [PATCH] Introduce hardbool attribute for C

[Alexandre Oliva <oliva@adacore.com>]

On Jul  8, 2022, Richard Biener <richard.guenther@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>