Re: [PATCH] Introduce hardbool attribute for C

[Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>]

On 6 April 2023 08:11:11 CEST, Alexandre Oliva <oliva@adacore.com> wrote:
>On Apr  2, 2023, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:
>
>> On Tue, 09 Aug 2022 10:53:08 -0300
>> Alexandre Oliva via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>
>>> Ping? (sorry, Joseph, I failed to Cc: you last time)
>
>> Didn't move yet did it.
>
>'fraid not, and surely it's too late for it to make gcc-13.
>

In fortran we have the following per the language:

---8<---
5 18.2.2 Named constants and derived types in the module
26 1 The entities listed in the second column of Table 18.2 shall be default integer named constants.
27 2 A Fortran intrinsic type whose kind type parameter is one of the values in the module shall have the same
28 representation as the C type with which it interoperates, for each value that a variable of that type can have.
29 For C_BOOL, the internal representation of .TRUE._C_BOOL and .FALSE._C_BOOL shall be the same as those of
30 the C values (_Bool)1 and (_Bool)0 respectively.

[]

12 5 The value of C_BOOL shall be a valid value for a logical kind parameter on the processor or shall be −1.
---8<---
thus we should probably be careful as i guess this might not work interoperable out of the box, fwiw. Not sure how realistic such a usecase would be..

I personally like your proposed 0 and ~0, that's probably pretty robust.
thanks,