Re: [PATCH] Introduce hardbool attribute for C

Re: [PATCH] Introduce hardbool attribute for C

[Bernhard Reutner-Fischer]

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,

Re: [PATCH] Introduce hardbool attribute for C

[Alexandre Oliva]

On Apr  6, 2023, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:

> 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.

I'm not changing any of the standard types, FWIW.  The proposed
extension enables alternate boolean types to be introduced, with
extra checking for hardening.

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

That is only a default.  Certain applications may benefit from other
values.  0xa5 and 0x5a seem to make a good combination too.

-- 
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>

Re: [PATCH] Introduce hardbool attribute for C

[Thomas Koenig]

Hi Alexandre,

> On Apr  6, 2023, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:
> 
>> 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.
> 
> I'm not changing any of the standard types, FWIW.  The proposed
> extension enables alternate boolean types to be introduced, with
> extra checking for hardening.
> 
>> I personally like your proposed 0 and ~0, that's probably pretty robust.
> 
> That is only a default.  Certain applications may benefit from other
> values.  0xa5 and 0x5a seem to make a good combination too.
In gfortran, we depend on the representation of 0/1 for several things
(among them avoiding having separate library versions for logical
kind=1,2,4,8,16 for MASK).

So, such a type would be incompatible with vanilla LOGICAL variables
and with C interop logical variables.

If anybody should pass such a hardbool variable to Fortran, they
will get unpredictable results, and deserve to lose.  The opposite
effect of what would be intended :-)

Best regards

	Thomas

Re: [PATCH] Introduce hardbool attribute for C

[Alexandre Oliva]

On Jun 16, 2023, Thomas Koenig <tkoenig@netcologne.de> wrote:

> So, such a type would be incompatible with vanilla LOGICAL variables
> and with C interop logical variables.

Yeah, it would.  It's something else, and if you choose to use such a
type in an interface, it would need to be handled as such.  Presumably,
absent direct support in the desired language, using the underlying type
and the explicitly chosen constants would work.

This is nothing to call home about.  It's not unusual for languages to
support features that are not directly representable in other languages.
And this is one that isn't even hard to work around.

But I'd first doubt the wisdom of whoever adds such a type to a
cross-language interface.

-- 
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>

Re: [PATCH] Introduce hardbool attribute for C

[Bernhard Reutner-Fischer]

On 16 June 2023 07:35:27 CEST, Alexandre Oliva via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:

index 0000000000000..634feaed4deef
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/hardbool-err.c
@@ -0,0 +1,28 @@
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+typedef _Bool __attribute__ ((__hardbool__))
+hbbl; /* { dg-error "integral types" } */
+
+typedef double __attribute__ ((__hardbool__))
+hbdbl; /* { dg-error "integral types" } */
+
+enum x;
+typedef enum x __attribute__ ((__hardbool__))
+hbenum; /* { dg-error "integral types" } */
+
+struct s;
+typedef struct s __attribute__ ((__hardbool__))
+hbstruct; /* { dg-error "integral types" } */
+
+typedef int __attribute__ ((__hardbool__ (0, 0)))
+hb00; /* { dg-error "different values" } */
+
+typedef int __attribute__ ((__hardbool__ (4, 16))) hb4x;
+struct s {
+ hb4x m:2;
+}; /* { dg-error "is a GCC extension|different values" } */
+/* { dg-warning "changes value" "warning" { target *-*-* } .-1 } */
+
+hb4x __attribute__ ((vector_size (4 * sizeof (hb4x))))
+vvar; /* { dg-error "invalid vector type" } */

Arm-chair, tinfoil hat still on, didn't look closely, hence:

I don't see explicit tests with _Complex nor __complex__. Would we want to check these here, or are they handled thought the "underlying" tests above?

I'd welcome a fortran interop note in the docs as hinted previously to cover out of the box behavior. It's probably reasonably unlikely but better be safe than sorry?
cheers,

Re: [PATCH] Introduce hardbool attribute for C

[Alexandre Oliva]

Thanks for the test.

Did you mean for me to incorporate it into the patch, or do you mean to
contribute it separately, if the feature happens to be accepted?

On Jun 19, 2023, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:

> I don't see explicit tests with _Complex nor __complex__. Would we
> want to check these here, or are they handled thought the "underlying"
> tests above?

Good question.  The notion of using complex types to hold booleans
hadn't even crossed my mind.

On the one hand, there doesn't seem to be reason to rule them out, and
that could go for literally any other type.

On the other, there doesn't seem to be any useful case for them.  Can
anyone think of one?

> I'd welcome a fortran interop note in the docs

Is there any good place for such interop notes?  I'm not sure I'm
best-suited to write them up, since Fortran is not a language I'm
very familiar with, but I suppose I could give it a try.

-- 
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>

Re: [PATCH] Introduce hardbool attribute for C

[Bernhard Reutner-Fischer]

On Wed, 21 Jun 2023 22:08:55 -0300
Alexandre Oliva <oliva@adacore.com> wrote:

> Thanks for the test.
> 
> Did you mean for me to incorporate it into the patch, or do you mean to
> contribute it separately, if the feature happens to be accepted?

These were your tests that i quoted but i or my MUA botched to add one
level of quotes -- sorry for that.

> 
> On Jun 19, 2023, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:
> 
> > I don't see explicit tests with _Complex nor __complex__. Would we
> > want to check these here, or are they handled thought the "underlying"
> > tests above?  
> 
> Good question.  The notion of using complex types to hold booleans
> hadn't even crossed my mind.

Maybe it is not real, it just sparkled through somehow.

> On the one hand, there doesn't seem to be reason to rule them out, and
> that could go for literally any other type.
> 
> On the other, there doesn't seem to be any useful case for them.  Can
> anyone think of one?

We could either not reject other such uses and wait or we could reject
them and equally wait for complaints. I would not dare to bet who pops
up first, fuzzers or users, though arguments of the latter would
probably be interesting.. I don't have an opinion (nor a use-case),
really, it was just a thought (i mentioned tinfoil hat, did i ;).

> 
> > I'd welcome a fortran interop note in the docs  
> 
> Is there any good place for such interop notes?  I'm not sure I'm
> best-suited to write them up, since Fortran is not a language I'm
> very familiar with, but I suppose I could give it a try.
> 

I'd append to your extend.texi hunk below the para about uninitialized a
note to the effect of:
Note: Types annotated with this attribute may not be Fortran
interoperable.

I would not go into too much detail about C_BOOL nor LOGICAL for i
reckon anybody sensibilised to either two of that attribute, C and
Fortran will draw her conclusions.
Didn't really think how easy it would be to handle this on the user
side, but i fear the modern iso_c_binding way would need help from the
compiler for the lazy. I'd expect a user to be able to trivially
translate this in wrappers done the old way though, which is a pity
from an educational and modernisation POV. Didn't look closely, so this
guesstimate might be all wrong, of course.

thanks,

Re: [PATCH] Introduce hardbool attribute for C

[Alexandre Oliva]

On Jun 22, 2023, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:

> On Wed, 21 Jun 2023 22:08:55 -0300
> Alexandre Oliva <oliva@adacore.com> wrote:

>> Thanks for the test.
>> 
>> Did you mean for me to incorporate it into the patch, or do you mean to
>> contribute it separately, if the feature happens to be accepted?

> These were your tests that i quoted

Aaah.  I didn't look too closely, I just assumed you'd tweaked something
in there.

>> > I don't see explicit tests with _Complex nor __complex__. Would we
>> > want to check these here, or are they handled thought the "underlying"
>> > tests above?  
>> 
>> Good question.  The notion of using complex types to hold booleans
>> hadn't even crossed my mind.

> Maybe it is not real, it just sparkled through somehow.

Is it imaginary, then? :-D

>> On the other, there doesn't seem to be any useful case for them.  Can
>> anyone think of one?

> We could either not reject other such uses and wait or we could reject
> them and equally wait for complaints. I would not dare to bet who pops
> up first, fuzzers or users

I bet on fuzzers :-)

> it was just a thought (i mentioned tinfoil hat, did i ;).

indeed ;-)

Having verified that it gets rejected (phew :-) I'm inclined to add it
to the test you quoted and be done with it.  If a reason ever comes up
to support it, the test can be adjusted accordingly.

>> 
>> > I'd welcome a fortran interop note in the docs  
>> 
>> Is there any good place for such interop notes?  I'm not sure I'm
>> best-suited to write them up, since Fortran is not a language I'm
>> very familiar with, but I suppose I could give it a try.

> I'd append to your extend.texi hunk below the para about uninitialized a
> note to the effect of:
> Note: Types annotated with this attribute may not be Fortran
> interoperable.

I'm not comfortable single-casing Fortran like that.  I expect other
languages could face similar interop issues when relying on
single-language extensions.  How about:

  Since this is a language extension only available in C, interoperation
  with other languages may pose difficulties.  It should interoperate
  with Ada Booleans defined with the same size and equivalent
  representation clauses, and with enumerations or other languages'
  integral types that correspond to C's chosen integral type.

-- 
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>