From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rock.gnat.com (rock.gnat.com [205.232.38.15]) by sourceware.org (Postfix) with ESMTPS id 129053850231 for ; Fri, 8 Jul 2022 15:29:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 129053850231 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id DB9F011689E; Fri, 8 Jul 2022 11:29:04 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at gnat.com Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5fKnw1li3giU; Fri, 8 Jul 2022 11:29:04 -0400 (EDT) Received: from free.home (tron.gnat.com [IPv6:2620:20:4000:0:46a8:42ff:fe0e:e294]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPS id A08B01166B0; Fri, 8 Jul 2022 11:29:04 -0400 (EDT) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 268FSvi01212457 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 8 Jul 2022 12:28:57 -0300 From: Alexandre Oliva To: Richard Biener Cc: GCC Patches Subject: Re: [PATCH] Introduce hardbool attribute for C Organization: Free thinker, does not speak for AdaCore References: Errors-To: aoliva@lxoliva.fsfla.org Date: Fri, 08 Jul 2022 12:28:57 -0300 In-Reply-To: (Richard Biener's message of "Fri, 8 Jul 2022 08:58:34 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2022 15:29:06 -0000 On Jul 8, 2022, Richard Biener 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