On 6 April 2023 08:11:11 CEST, Alexandre Oliva <ol...@adacore.com> wrote: >On Apr 2, 2023, Bernhard Reutner-Fischer <rep.dot....@gmail.com> wrote: > >> On Tue, 09 Aug 2022 10:53:08 -0300 >> Alexandre Oliva via Gcc-patches <gcc-patc...@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,
