On 05/02/2022 13:23, David Brown wrote:
> On 04/02/2022 20:38, Bart wrote:
>> On 04/02/2022 10:06, David Brown wrote:
>
>>> Secondly, there are technical differences.  The conversion of an integer
>>> "x" to a _Bool "b" is effectively "b = !!x;".  You are guaranteed that
>>> "b" is either 0 or 1 - and the compiler can use that knowledge for
>>> optimisation (as can the programmer).  This can mean some operations
>>> (such as conversion from an integer) may be less efficient, but other
>>> operations (such as logical operations) are more efficient.  Overall, it
>>> is usually a win.
>>
>> You're never really quite sure what's happening with _Bool.
>>
>> There's little control over its size. And in A program like this:
>>
>>     union {
>>         _Bool a;
>>         unsigned char b;
>>     } x;
>>
>>     x.b=0x55;
>>     printf("A= %X\n", x.a);
>>     printf("B= %X\n", x.b);
>>
>
> <snip>
>
>> You can probably claim this is due to UB or whatever, but the fact
>> remains that using regular int types, the results will be consistent and
>> predictable across all compilers. It /is/ possible for the byte value
>> that usually represents a bool type to be set something that is neither
>> true (1) or false (0).
>>
>
> It /is/ undefined behaviour. (6.2.6.1p5 covers it, though I doubt if
> you care.) It is also common sense. A _Bool contains either 0 or 1 -
> any other value is invalid and can't be achieved without extraordinary
> effort designed purely to make bad code.
>
> Yes, you know /exactly/ what is happening with _Bool - write sane code,
> and you get the results you expect. Write code with clear and
> intentional errors with the sole intention of getting inconsistent
> results, and you get exactly what you expect.

My point is exactly that you don't know what's going on, if not because
it's UB, it's because it's implementation defined or for some other
weird reason. Take this:

_Bool a=0;

for (int i=0; i<10; ++i){
printf("%d ",a);
++a;
}

What will be the output? For ++a, it's:

0 1 1 1 1 1 ...

But for --a it's:

0 1 0 1 0 1 ...

(With MSVC, it's all zeros. With 2 lesser compilers, it's 0 -1 -2 -3 ...)

Try this:

a = 1;
++a;
--a;

Normally ++ and -- cancel out, but here a ends up as 0. But reverse the
increments, and now the result is 1.

_Bool has special semantics compared with int, yet the language still
allows you to do all things associated with int.

What is type result type of !!? It is int, not _Bool. _Bool is a
half-hearted attempt at a proper Boolean type. I prefer to use 0 and 1
values of int, or 0 and non-zero, then I know exactly where I'm at.

On 05/02/2022 16:16, Bart wrote:
> On 05/02/2022 13:23, David Brown wrote:
>> On 04/02/2022 20:38, Bart wrote:
>>> On 04/02/2022 10:06, David Brown wrote:
>>
>>>> Secondly, there are technical differences.  The conversion of an
>>>> integer
>>>> "x" to a _Bool "b" is effectively "b = !!x;".  You are guaranteed that
>>>> "b" is either 0 or 1 - and the compiler can use that knowledge for
>>>> optimisation (as can the programmer).  This can mean some operations
>>>> (such as conversion from an integer) may be less efficient, but other
>>>> operations (such as logical operations) are more efficient. 
>>>> Overall, it
>>>> is usually a win.
>>>
>>> You're never really quite sure what's happening with _Bool.
>>>
>>> There's little control over its size. And in A program like this:
>>>
>>>      union {
>>>          _Bool a;
>>>          unsigned char b;
>>>      } x;
>>>
>>>      x.b=0x55;
>>>      printf("A= %X\n", x.a);
>>>      printf("B= %X\n", x.b);
>>>
>>
>> <snip>
>>
>>> You can probably claim this is due to UB or whatever, but the fact
>>> remains that using regular int types, the results will be consistent and
>>> predictable across all compilers. It /is/ possible for the byte value
>>> that usually represents a bool type to be set something that is neither
>>> true (1) or false (0).
>>>
>>
>> It /is/ undefined behaviour.  (6.2.6.1p5 covers it, though I doubt if
>> you care.)  It is also common sense.  A _Bool contains either 0 or 1 -
>> any other value is invalid and can't be achieved without extraordinary
>> effort designed purely to make bad code.
>>
>> Yes, you know /exactly/ what is happening with _Bool - write sane code,
>> and you get the results you expect.  Write code with clear and
>> intentional errors with the sole intention of getting inconsistent
>> results, and you get exactly what you expect.
>
> My point is exactly that you don't know what's going on, if not because
> it's UB, it's because it's implementation defined or for some other
> weird reason. Take this:
>
>     _Bool a=0;
>
>     for (int i=0; i<10; ++i){
>         printf("%d  ",a);
>         ++a;
>     }
>
> What will be the output? For ++a, it's:
>
>   0 1 1 1 1 1 ...

++a means (a += 1), which in turn means (a = a + 1). The boolean is
converted to an int (either 0 or 1), and 1 is added giving either 1 or
2. Conversion back to _Bool is on the basis of comparison to 0 - since
neither 1 nor 2 compares equal to 0, the result of "++a" will always
leave "a" as "true".

>
> But for --a it's:
>
>   0 1 0 1 0 1 ...

Similar reasoning - if "a" is currently "true", then after "--a" it is
left as "false". If "a" is currently "false", then "a = a - 1" will
give "a = -1", and thus set "a" to "true" (1).

It's not hard, not UB, not unexpected. (It is also almost certainly not
found in real code, which is why compilers like gcc with "-Wall" will
warn you that it's probably a mistake in your code. And in C++, it is
not allowed at all.)

>
> (With MSVC, it's all zeros. With 2 lesser compilers, it's 0 -1 -2 -3 ...)

MSVC is primarily a C++ compiler, not a C compiler. I don't have access
to it other than via <https://godbolt.org>, and there it is only C++.
But almost certainly, you have made an error - it seems far more likely
than supposing MS failed to correctly implement _Bool in C.

For the "lesser compilers", you are clearly using an "int", not a "_Bool".

>
> Try this:
>
>     a = 1;
>     ++a;
>     --a;
>
> Normally ++ and -- cancel out, but here a ends up as 0. But reverse the
> increments, and now the result is 1.

"_Bool" is not "int". Why would you think it acts like it?

>
> _Bool has special semantics compared with int, yet the language still
> allows you to do all things associated with int.
>
> What is type result type of !!? It is int, not _Bool. _Bool is a
> half-hearted attempt at a proper Boolean type. I prefer to use 0 and 1
> values of int, or 0 and non-zero, then I know exactly where I'm at.

The logical and relational operators in C evaluate to "int", values 0 or
1, preceding the introduction of _Bool to the language.

The fact that you personally get confused about _Bool and don't
understand what it is and how it is defined, does not mean that it is
unclear, confusing, imprecise, or that anyone else fails to comprehend it.

However, now you know the rules that apply even when doing something as
deliberately unrealistic and pointless as incrementing or decrementing a
boolean variable. So you can no longer claim that you don't understand
it, or are not sure what is going on, and can now happily make use of
this extremely useful type.

On 05/02/2022 16:27, David Brown wrote:
> On 05/02/2022 16:16, Bart wrote:

> The fact that you personally get confused about _Bool and don't
> understand what it is and how it is defined, does not mean that it is
> unclear, confusing, imprecise, or that anyone else fails to comprehend it.
>
> However, now you know the rules that apply even when doing something as
> deliberately unrealistic and pointless as incrementing or decrementing a
> boolean variable. So you can no longer claim that you don't understand
> it, or are not sure what is going on, and can now happily make use of
> this extremely useful type.

OK, so I see _Bool used in APIs which I might want to call via an FFI.

Which more universal type is most likely to correspond to it? What are
the actual values I can expect to see across all bits? What assumptions
can I make?

I'd quite like to know those answers when coding in C too!

On Saturday, 5 February 2022 at 13:12:32 UTC, David Brown wrote:
> On 04/02/2022 15:53, Mateusz Viste wrote:
> > 2022-02-04 at 15:27 +0100, David Brown wrote:
> >> That is a completely separate issue, and nothing to do with the
> >> question, which was "what advantages are there to using _Bool over an
> >> plain integer type?".
> >
> > I think that in a vicious way, it is not separate.
> >
> >> Yes, it's hard to see what
> >> SetSpnEdit(height_spn, height, true, false, false);
> >>
> >> is doing. But you don't make anything better by writing
> >> SetSpnEdit(height_spn, height, 1, 0, 0);
> >
> > If I would be a user of _Bool, I'd be very tempted to use the first form
> > (and end up with a hardly readable line).
> I think you need to work on your temptation issues. When a language
> supports a feature, you are not /required/ to use it just because it is
> there. There are perhaps a dozen different ways to make the call to
> SetSpnEdit clearer and safer - none of them are in any way broken by the
> existence of "_Bool".
> > I guess it's a vicious side effect of the human mind - "if I have a
> > hammer, then everything looks like nails". :-)
> >
> You seem to be limiting yourself severely as a programmer. How you code
> is of course up to you, but please do not assume all programmers are
> going to see things that way.
>
> And your analogy is all wrong. You are claiming that because you only
> have a hammer (int), you are better equipped to invent a spanner when
> you need it than people who also have access to a screwdriver (_Bool).
>
>
> There is an argument to be made that the power of a programming language
> comes from what it stops you from doing just as much as from what it
> allows you to do, and that more features and possibilities allows for
> more misuse as well as more good usage.
>
Yes. In C you can't refer to anything outside the source file, unless you
import it via a header or declare it "extern" in that source file. That's a good
restriction that keeps code modular. You can't use non-Latin identifiers,
which is another good rule, because most educated people can read Latin
script, but most programmers can't read most of the other alphabets in
existence.
You could enforce a rule that a function cannot take more than one boolean
parameter. That would prevent a castastophe such as SetSpnEdit. But
language standards committees are reluctant to pass stylistic rules like
that.
Goto is considered harmful. So some languages disallowed it. However it's
often had to be put back in, because automatic code generators which are
banned from using goto are harder to write. That's an example of how improving
a language by removing abiliites can be double-edged.

On Saturday, February 5, 2022 at 10:17:11 AM UTC-5, Bart wrote:
....
> My point is exactly that you don't know what's going on, if not because
> it's UB, it's because it's implementation defined or for some other
> weird reason. Take this:
>
> _Bool a=0;
>
> for (int i=0; i<10; ++i){
> printf("%d ",a);
> ++a;
> }
>
> What will be the output? For ++a, it's:
>
> 0 1 1 1 1 1 ...
>
> But for --a it's:
>
> 0 1 0 1 0 1 ...
>
> (With MSVC, it's all zeros. With 2 lesser compilers, it's 0 -1 -2 -3 ...)
>
> Try this:
>
> a = 1;
> ++a;
> --a;
>
> Normally ++ and -- cancel out, but here a ends up as 0. But reverse the
> increments, and now the result is 1.
>
> _Bool has special semantics compared with int, yet the language still
> allows you to do all things associated with int.
>
> What is type result type of !!? It is int, not _Bool. _Bool is a
> half-hearted attempt at a proper Boolean type. I prefer to use 0 and 1
> values of int, or 0 and non-zero, then I know exactly where I'm at.

The rules are really quite simple: _Bool expressions get promoted to int values of either 0 or 1, depending upon whether the _Bool value is false or true. During the evaluation of all expressions, those values behave the same as any other int with a value of 0 or 1. On conversion to _Bool, values that compare equal to zero get converted to false, all other values convert to true. Everything you've observed is explained by those simple rules, except for the behavior you've described for "2 lesser compilers", which is non-conforming. You can't blame C for the behavior of compilers that fail to to conform to its rules.

On Friday, February 4, 2022 at 2:39:14 PM UTC-5, Bart wrote:
....
> union {
> _Bool a;
> unsigned char b;
> } x;
>
> x.b=0x55;
> printf("A= %X\n", x.a);
> printf("B= %X\n", x.b);
>
> if (x.a == true) puts("A is True");
> if (x.a == false) puts("A is False");
> if (x.a != true && x.a != false) puts("A is neither True nor False");
>
> different compilers show different results, including this from gcc -O0:
>
> A= 55
> B= 55
> A is True
> A is False
> A is neither True nor False
>
> MSVC shows this:
>
> A= 55
> B= 55
> A is neither True nor False
>
> while Clang, and gcc -O3, displays:
>
> A= 1
> B= 55
> A is True
>
> You can probably claim this is due to UB or whatever, but the fact
> remains that using regular int types, the results will be consistent and
> predictable across all compilers.

Could you name a single type other than char, unsigned char, or signed
char, that could be used to replace _Bool in that code, which would result
in your code having consistent results on all implementations?
Type punning between incompatible types almost always has, at best,
implementation-defined results. The only reason that signed char would
work is this particular case is that the signed and unsigned versions of char
are mandated to have the same representation for positive values of signed
char, making them semi-compatible. Even that would disappear if your code had
used a value greater than SCHAR_MAX.

On 05/02/2022 17:38, james...@alumni.caltech.edu wrote:
> On Saturday, February 5, 2022 at 10:17:11 AM UTC-5, Bart wrote:
> ...
>> My point is exactly that you don't know what's going on, if not because
>> it's UB, it's because it's implementation defined or for some other
>> weird reason. Take this:
>>
>> _Bool a=0;
>>
>> for (int i=0; i<10; ++i){
>> printf("%d ",a);
>> ++a;
>> }
>>
>> What will be the output? For ++a, it's:
>>
>> 0 1 1 1 1 1 ...
>>
>> But for --a it's:
>>
>> 0 1 0 1 0 1 ...
>>
>> (With MSVC, it's all zeros. With 2 lesser compilers, it's 0 -1 -2 -3 ...)
>>
>> Try this:
>>
>> a = 1;
>> ++a;
>> --a;
>>
>> Normally ++ and -- cancel out, but here a ends up as 0. But reverse the
>> increments, and now the result is 1.
>>
>> _Bool has special semantics compared with int, yet the language still
>> allows you to do all things associated with int.
>>
>> What is type result type of !!? It is int, not _Bool. _Bool is a
>> half-hearted attempt at a proper Boolean type. I prefer to use 0 and 1
>> values of int, or 0 and non-zero, then I know exactly where I'm at.
>
> The rules are really quite simple: _Bool expressions get promoted to int values of either 0 or 1, depending upon whether the _Bool value is false or true. During the evaluation of all expressions, those values behave the same as any other int with a value of 0 or 1. On conversion to _Bool, values that compare equal to zero get converted to false, all other values convert to true. Everything you've observed is explained by those simple rules,

It doesn't explain the behaviour of MSVC [19.28.29337 for x64], which
outputs all zeros. Maybe another non-conforming one?

> except for the behavior you've described for "2 lesser compilers", which is non-conforming. You can't blame C for the behavior of compilers that fail to to conform to its rules.

On 05/02/2022 17:50, james...@alumni.caltech.edu wrote:
> On Friday, February 4, 2022 at 2:39:14 PM UTC-5, Bart wrote:
> ...
>> union {
>> _Bool a;
>> unsigned char b;
>> } x;
>>
>> x.b=0x55;
>> printf("A= %X\n", x.a);
>> printf("B= %X\n", x.b);
>>
>> if (x.a == true) puts("A is True");
>> if (x.a == false) puts("A is False");
>> if (x.a != true && x.a != false) puts("A is neither True nor False");
>>
>> different compilers show different results, including this from gcc -O0:
>>
>> A= 55
>> B= 55
>> A is True
>> A is False
>> A is neither True nor False
>>
>> MSVC shows this:
>>
>> A= 55
>> B= 55
>> A is neither True nor False
>>
>> while Clang, and gcc -O3, displays:
>>
>> A= 1
>> B= 55
>> A is True
>>
>> You can probably claim this is due to UB or whatever, but the fact
>> remains that using regular int types, the results will be consistent and
>> predictable across all compilers.
>
>
> Could you name a single type other than char, unsigned char, or signed
> char,

Why other than those types? They are the only choices if I wanted an
8-bit boolean representation. With 'char' used in place of _Bool, then
all compilers I tried have the same output, that of MSVC above, with
both members having values of 0x55, and .a being neither true/1 nor
false/0, which it isn't.

gcc had the most bizarre behaviour where .a was simultaneously both true
and not true, and both false and not false!

Using a wider type for .a than .b would give more unpredictable results,
but for reasons that are obvious across all compilers: the top bits of
..a will be garbage.

On 2/5/22 12:57 PM, Bart wrote:
>
> It doesn't explain the behaviour of MSVC [19.28.29337 for x64], which
> outputs all zeros. Maybe another non-conforming one?

Could the code have been compiled as C++, it uses different rules.

If I remember right, in C++ if x is a bool, then x-- is defined to set x
false and return the previous value of x, a test and clear instruction.

On 2/5/22 05:40, Mateusz Viste wrote:
> 2022-02-04 at 21:14 -0800, Tim Rentsch wrote:
....
>> Number 9: array parameters may have 'static' and 'const' etc.
>> Normally I use array notation (eg, 'int x[]') for parameters
>> that are treated as arrays rather than as pointers to single
>> objects. This feature allows length and qualifier information to
>> be added to the pointer parameter while still retaining array
>> notation in the parameter declaration.
>
> I am not sure I understand this one (and I also never use array
> notation in function parameters). Are you referring to such construct?
>
> void pupa(const char s[]) {
> printf("%c", s[0]);
> }
>
> Apparently this passes without warnings in both c89 and c99 modes of
> clang and gcc. But I probably misunderstood you.

He's referring to two separate features that were introduced in C99. In
all versions of standard C, all three of the following declarations have
exactly the same meaning:

void func(int []);
void func(int [25536]);
void func(int *);

This only applies to the leading dimension of pointers that are declared
as if they were arrays.

And the same is true of the corresponding K&R style definitions:
void func(a)
int a[];
{ }

void func(a)
int a[25536];
{ }

void func(a)
int *a;
{ }

You can debate the desirability of this feature, but it goes all the way
back to K&R C, and there's lots of code written using each of the three
different ways a pointer parameter can be declared.

In C99, the committee added the feature that you could put one or more
qualifiers (const, volatile, or restrict) into the first dimension of a
pointer parameter declared as if it was an array, and the effect would
be the same as if the qualifier was used in the appropriate location in
an ordinary pointer declaration:

int qualified(int array[const]);

means exactly the same thing as

int qualified(const int *array);

In C2011, _Atomic was added to the list of qualifiers.

The other feature is that you can declare a function parameter as follows:

double limited(float [static 36]);

"If the keyword static also appears within the [ and ] of the array type
derivation, then for each call to the function, the value of the
corresponding actual argument shall provide access to the first element
of an array with at least as many elements as specified by the size
expression." (7.5.3p7).

Violating this "shall" has undefined behavior (4p2), which doesn't sound
like much of an advantage. However, that also allows implementations to
warn you with a diagnostic, if they can determine that your code might
violate that requirement. If they can determine that it will
unconditionally violate that requirement, they can even reject the
program at compile time. It's that non-mandatory diagnostic that I
consider valuable. It cannot, unfortunately, be made mandatory, because
in many cases it's difficult, and often even impossible, to determine at
compile time whether a piece of code will violate that requirement. But
when it can be determined, I consider that a very valuable warning. YMMV.

On 2/5/22 5:27 PM, David Brown wrote:
> On 05/02/2022 16:16, Bart wrote:
>> On 05/02/2022 13:23, David Brown wrote:
>>> On 04/02/2022 20:38, Bart wrote:
>>>> On 04/02/2022 10:06, David Brown wrote:
>>>
>>>>> Secondly, there are technical differences.  The conversion of an
>>>>> integer
>>>>> "x" to a _Bool "b" is effectively "b = !!x;".  You are guaranteed that
>>>>> "b" is either 0 or 1 - and the compiler can use that knowledge for
>>>>> optimisation (as can the programmer).  This can mean some operations
>>>>> (such as conversion from an integer) may be less efficient, but other
>>>>> operations (such as logical operations) are more efficient.
>>>>> Overall, it
>>>>> is usually a win.
>>>>
>>>> You're never really quite sure what's happening with _Bool.
>>>>
>>>> There's little control over its size. And in A program like this:
>>>>
>>>>      union {
>>>>          _Bool a;
>>>>          unsigned char b;
>>>>      } x;
>>>>
>>>>      x.b=0x55;
>>>>      printf("A= %X\n", x.a);
>>>>      printf("B= %X\n", x.b);
>>>>
>>>
>>> <snip>
>>>
>>>> You can probably claim this is due to UB or whatever, but the fact
>>>> remains that using regular int types, the results will be consistent and
>>>> predictable across all compilers. It /is/ possible for the byte value
>>>> that usually represents a bool type to be set something that is neither
>>>> true (1) or false (0).
>>>>
>>>
>>> It /is/ undefined behaviour.  (6.2.6.1p5 covers it, though I doubt if
>>> you care.)  It is also common sense.  A _Bool contains either 0 or 1 -
>>> any other value is invalid and can't be achieved without extraordinary
>>> effort designed purely to make bad code.
>>>
>>> Yes, you know /exactly/ what is happening with _Bool - write sane code,
>>> and you get the results you expect.  Write code with clear and
>>> intentional errors with the sole intention of getting inconsistent
>>> results, and you get exactly what you expect.
>>
>> My point is exactly that you don't know what's going on, if not because
>> it's UB, it's because it's implementation defined or for some other
>> weird reason. Take this:
>>
>>     _Bool a=0;
>>
>>     for (int i=0; i<10; ++i){
>>         printf("%d  ",a);
>>         ++a;
>>     }
>>
>> What will be the output? For ++a, it's:
>>
>>   0 1 1 1 1 1 ...
>
> ++a means (a += 1), which in turn means (a = a + 1). The boolean is
> converted to an int (either 0 or 1), and 1 is added giving either 1 or
> 2. Conversion back to _Bool is on the basis of comparison to 0 - since
> neither 1 nor 2 compares equal to 0, the result of "++a" will always
> leave "a" as "true".
>
>>
>> But for --a it's:
>>
>>   0 1 0 1 0 1 ...
>
> Similar reasoning - if "a" is currently "true", then after "--a" it is
> left as "false". If "a" is currently "false", then "a = a - 1" will
> give "a = -1", and thus set "a" to "true" (1).
>
> It's not hard, not UB, not unexpected. (It is also almost certainly not
> found in real code, which is why compilers like gcc with "-Wall" will
> warn you that it's probably a mistake in your code. And in C++, it is
> not allowed at all.)
>

[snip anything about MSVC]

Your explanation is correct, but I still think that Bart has a point.
This example shows that, as it has been designed, _Bool is not
completely a self-consistent type.

There is no reason why a boolean type should behave as shown with ++ and --.

The fact that this is the result of an implicit round trip to and from
'int' shows that _Bool is to some extent still intermingled with 'int',
despite the intention of making a true boolean type to get rid of the
traditional use of 'int' for this purpose.

I know that this is still an extreme example, and I wouldn't write code
like this:

Obviously, if a is a _Bool, "a++" should be replaced with "a = true",
and "a--" should be replaced with "a = !a"

However, the fact that writing "a++" and "a--" is allowed gives Bart a
point, IMO.

>
> The logical and relational operators in C evaluate to "int", values 0 or
> 1, preceding the introduction of _Bool to the language.
>
> The fact that you personally get confused about _Bool and don't
> understand what it is and how it is defined, does not mean that it is
> unclear, confusing, imprecise, or that anyone else fails to comprehend it.
>
> However, now you know the rules that apply even when doing something as
> deliberately unrealistic and pointless as incrementing or decrementing a
> boolean variable. So you can no longer claim that you don't understand
> it, or are not sure what is going on, and can now happily make use of
> this extremely useful type.
>

One might argue that the fact that the rules explain the result do not
make the rules right.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 2/5/22 05:40, Mateusz Viste wrote:
>> 2022-02-04 at 21:14 -0800, Tim Rentsch wrote:
> ...
>>> Number 9: array parameters may have 'static' and 'const' etc.
>>> Normally I use array notation (eg, 'int x[]') for parameters
>>> that are treated as arrays rather than as pointers to single
>>> objects. This feature allows length and qualifier information to
>>> be added to the pointer parameter while still retaining array
>>> notation in the parameter declaration.
>>
>> I am not sure I understand this one (and I also never use array
>> notation in function parameters). Are you referring to such construct?
>>
>> void pupa(const char s[]) {
>> printf("%c", s[0]);
>> }
>>
>> Apparently this passes without warnings in both c89 and c99 modes of
>> clang and gcc. But I probably misunderstood you.
>
> He's referring to two separate features that were introduced in C99.
<cut>
> In C99, the committee added the feature that you could put one or more
> qualifiers (const, volatile, or restrict) into the first dimension of a
> pointer parameter declared as if it was an array, and the effect would
> be the same as if the qualifier was used in the appropriate location in
> an ordinary pointer declaration:
>
> int qualified(int array[const]);
>
> means exactly the same thing as
>
> int qualified(const int *array);

I don't think so. It means the same as

int qualified(int *const array);

6.7.6.3 p7:

A declaration of a parameter as "array of type" shall be adjusted to
"qualified pointer to type", where the type qualifiers (if any) are
those specified within the [ and ] of the array type derivation.

It is the implied pointer that is qualified.

<cut>
--
Ben.

On 2/5/22 17:18, Manfred wrote:
> On 2/5/22 5:27 PM, David Brown wrote:
....
> There is no reason why a boolean type should behave as shown with ++ and --.
>
> The fact that this is the result of an implicit round trip to and from
> 'int' shows that _Bool is to some extent still intermingled with 'int',
> despite the intention of making a true boolean type to get rid of the
> traditional use of 'int' for this purpose.

Well, what would you expect when applying arithmetic operators to
boolean values? If I weren't familiar with the C standard's
specifications for such things, I wouldn't have any expectations at all
- you shouldn't use such operators on boolean values.

....
>> However, now you know the rules that apply even when doing something as
>> deliberately unrealistic and pointless as incrementing or decrementing a
>> boolean variable. So you can no longer claim that you don't understand
>> it, or are not sure what is going on, and can now happily make use of
>> this extremely useful type.
>>
>
> One might argue that the fact that the rules explain the result do not
> make the rules right.

The committee is the ultimate authority with respect to the C standard -
there's no other authority against which their decisions can be compared
for correctness. You can say it's poorly designed, internally
inconsistent, inconsistent with existing architectures or other computer
languages, etc.; but to say it's wrong implies a standard of correctness
it can be compared with, and there is none. In C, the ++ operator does
what the C standard says it should do - you can decide whether or not
what it does is useful for you, but there's no basis for saying that
what the standard says about it is wrong.

On 2/5/22 18:30, Ben Bacarisse wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
....
>> In C99, the committee added the feature that you could put one or more
>> qualifiers (const, volatile, or restrict) into the first dimension of a
>> pointer parameter declared as if it was an array, and the effect would
>> be the same as if the qualifier was used in the appropriate location in
>> an ordinary pointer declaration:
>>
>> int qualified(int array[const]);
>>
>> means exactly the same thing as
>>
>> int qualified(const int *array);
>
> I don't think so. It means the same as
>
> int qualified(int *const array);
>
> 6.7.6.3 p7:
>
> A declaration of a parameter as "array of type" shall be adjusted to
> "qualified pointer to type", where the type qualifiers (if any) are
> those specified within the [ and ] of the array type derivation.
>
> It is the implied pointer that is qualified.

You're right, of course. I remembered it backwards, and didn't check. I
should have realized my mistake, because the feature wouldn't be needed
if it worked the way I specified - qualifiers before the '*' can be
specified just as easily when declaring a pointer parameter as if it
were an array, as when declaring it explicitly as a pointer.

On 05/02/2022 17:41, Bart wrote:
> On 05/02/2022 16:27, David Brown wrote:
>> On 05/02/2022 16:16, Bart wrote:
>
>> The fact that you personally get confused about _Bool and don't
>> understand what it is and how it is defined, does not mean that it is
>> unclear, confusing, imprecise, or that anyone else fails to comprehend
>> it.
>>
>> However, now you know the rules that apply even when doing something as
>> deliberately unrealistic and pointless as incrementing or decrementing a
>> boolean variable.  So you can no longer claim that you don't understand
>> it, or are not sure what is going on, and can now happily make use of
>> this extremely useful type.
>
> OK, so I see _Bool used in APIs which I might want to call via an FFI.
>
> Which more universal type is most likely to correspond to it? What are
> the actual values I can expect to see across all bits? What assumptions
> can I make?
>
> I'd quite like to know those answers when coding in C too!

When calling an API that takes a _Bool parameter, you follow whatever
the ABI for the platform says. I would expect that in most cases (I
don't know of any exceptions, but I haven't looked - and I'd be glad to
hear of them), a _Bool takes the same space and ABI conventions as an
unsigned char. So you can simply pass an unsigned char with value 0 or
1. But you do have to make sure it is either 0 or 1, nothing else.

When writing an FFI handler, /you/ are responsible for finding, reading
and understanding the appropriate ABI documents. C "_Bool" and C++
"bool" will be included there.

On 06/02/2022 11:01, David Brown wrote:
> On 05/02/2022 17:41, Bart wrote:
>> On 05/02/2022 16:27, David Brown wrote:
>>> On 05/02/2022 16:16, Bart wrote:
>>
>>> The fact that you personally get confused about _Bool and don't
>>> understand what it is and how it is defined, does not mean that it is
>>> unclear, confusing, imprecise, or that anyone else fails to comprehend
>>> it.
>>>
>>> However, now you know the rules that apply even when doing something as
>>> deliberately unrealistic and pointless as incrementing or decrementing a
>>> boolean variable.  So you can no longer claim that you don't understand
>>> it, or are not sure what is going on, and can now happily make use of
>>> this extremely useful type.
>>
>> OK, so I see _Bool used in APIs which I might want to call via an FFI.
>>
>> Which more universal type is most likely to correspond to it? What are
>> the actual values I can expect to see across all bits? What assumptions
>> can I make?
>>
>> I'd quite like to know those answers when coding in C too!
>
> When calling an API that takes a _Bool parameter, you follow whatever
> the ABI for the platform says. I would expect that in most cases (I
> don't know of any exceptions, but I haven't looked - and I'd be glad to
> hear of them), a _Bool takes the same space and ABI conventions as an
> unsigned char. So you can simply pass an unsigned char with value 0 or
> 1. But you do have to make sure it is either 0 or 1, nothing else.
>
> When writing an FFI handler, /you/ are responsible for finding, reading
> and understanding the appropriate ABI documents. C "_Bool" and C++
> "bool" will be included there.

The Win64 ABI mentions little about the actual types of primitives,
which is as it should be. It's mainly about sizes, and whether they are
floats or not. It should be language-neutral.

The System V x64 ABI starts with a long list of C types, which sounds
off - why make a special case for C, and not for any of innumerable
other languages? But this is Unix, where everyone knows that Unix and C
are very chummy.

In any case, the API is not the ABI. At the point at which I need to
choose a corresponding type to _Bool in the API, and have to be aware of
representation and semantics, I will not know the target, and therefore
the ABI.

For example, the SYSV ABI for x64 tells me that 'long' is a 64-bit type,
but that's not correct for Windows nor 32-bit Linux.

So the answer seems to be to just make assumptions.

BTW within Windows APIs, 'BOOL' is defined on top of 'int'.

On 05/02/2022 23:18, Manfred wrote:
> On 2/5/22 5:27 PM, David Brown wrote:
>> On 05/02/2022 16:16, Bart wrote:
>>> On 05/02/2022 13:23, David Brown wrote:
>>>> On 04/02/2022 20:38, Bart wrote:
>>>>> On 04/02/2022 10:06, David Brown wrote:
>>>>
>>>>>> Secondly, there are technical differences.  The conversion of an
>>>>>> integer
>>>>>> "x" to a _Bool "b" is effectively "b = !!x;".  You are guaranteed
>>>>>> that
>>>>>> "b" is either 0 or 1 - and the compiler can use that knowledge for
>>>>>> optimisation (as can the programmer).  This can mean some operations
>>>>>> (such as conversion from an integer) may be less efficient, but other
>>>>>> operations (such as logical operations) are more efficient.
>>>>>> Overall, it
>>>>>> is usually a win.
>>>>>
>>>>> You're never really quite sure what's happening with _Bool.
>>>>>
>>>>> There's little control over its size. And in A program like this:
>>>>>
>>>>>       union {
>>>>>           _Bool a;
>>>>>           unsigned char b;
>>>>>       } x;
>>>>>
>>>>>       x.b=0x55;
>>>>>       printf("A= %X\n", x.a);
>>>>>       printf("B= %X\n", x.b);
>>>>>
>>>>
>>>> <snip>
>>>>
>>>>> You can probably claim this is due to UB or whatever, but the fact
>>>>> remains that using regular int types, the results will be
>>>>> consistent and
>>>>> predictable across all compilers. It /is/ possible for the byte value
>>>>> that usually represents a bool type to be set something that is
>>>>> neither
>>>>> true (1) or false (0).
>>>>>
>>>>
>>>> It /is/ undefined behaviour.  (6.2.6.1p5 covers it, though I doubt if
>>>> you care.)  It is also common sense.  A _Bool contains either 0 or 1 -
>>>> any other value is invalid and can't be achieved without extraordinary
>>>> effort designed purely to make bad code.
>>>>
>>>> Yes, you know /exactly/ what is happening with _Bool - write sane code,
>>>> and you get the results you expect.  Write code with clear and
>>>> intentional errors with the sole intention of getting inconsistent
>>>> results, and you get exactly what you expect.
>>>
>>> My point is exactly that you don't know what's going on, if not because
>>> it's UB, it's because it's implementation defined or for some other
>>> weird reason. Take this:
>>>
>>>      _Bool a=0;
>>>
>>>      for (int i=0; i<10; ++i){
>>>          printf("%d  ",a);
>>>          ++a;
>>>      }
>>>
>>> What will be the output? For ++a, it's:
>>>
>>>    0 1 1 1 1 1 ...
>>
>> ++a means (a += 1), which in turn means (a = a + 1).  The boolean is
>> converted to an int (either 0 or 1), and 1 is added giving either 1 or
>> 2.  Conversion back to _Bool is on the basis of comparison to 0 - since
>> neither 1 nor 2 compares equal to 0, the result of "++a" will always
>> leave "a" as "true".
>>
>>>
>>> But for --a it's:
>>>
>>>    0 1 0 1 0 1 ...
>>
>> Similar reasoning - if "a" is currently "true", then after "--a" it is
>> left as "false".  If "a" is currently "false", then "a = a - 1" will
>> give "a = -1", and thus set "a" to "true" (1).
>>
>> It's not hard, not UB, not unexpected.  (It is also almost certainly not
>> found in real code, which is why compilers like gcc with "-Wall" will
>> warn you that it's probably a mistake in your code.  And in C++, it is
>> not allowed at all.)
>>
>
> [snip anything about MSVC]
>
> Your explanation is correct, but I still think that Bart has a point.
> This example shows that, as it has been designed, _Bool is not
> completely a self-consistent type.

I don't agree. What is inconsistent about it?

>
> There is no reason why a boolean type should behave as shown with ++ and
> --.

Yes, there is - it is the only sensible and consistent possibility for
C. _Bool is an unsigned integer type - any integer types whose values
are a subset of those of "int" get promoted to "int" before arithmetic
operations. You might not think that's the best way to design a
programming language (and you would certainly not be alone in that), but
it is the way C works.

C philosophy has always been to change as little of the existing
language as possible when adding new features - the behaviour of _Bool
in C was made to keep the definitions of operators unchanged.

When C++ was designed, they could take more freedoms - "bool" was there
from the start, and there was less need for compatibility with C
standards. Relational operators in C++ evaluate to a "bool", rather
than an "int", which is more sensible - but C could not make that change
without affecting the existing language and code.

As far as I know (and I haven't checked all the details), "--a" and
"a--" has never been allowed for booleans in C++, while "++a" and "a++"
were removed in C++17.

>
> The fact that this is the result of an implicit round trip to and from
> 'int' shows that _Bool is to some extent still intermingled with 'int',
> despite the intention of making a true boolean type to get rid of the
> traditional use of 'int' for this purpose.

Welcome to C :-)

It is no different from "char" or "short int" in this respect.

"_Bool" is not a strong boolean type, in the manner of - say - Pascal or
Ada. It is not as independent as in C++. It was made such that the
majority of code that used an "int" (or a char of some sort, or an
enumeration) to hold a boolean value could be changed to use _Bool and
still work the same - without causing other disruption to code. And in
additional to standardising a boolean type, it added the useful property
of always being 0 or 1.

>
> I know that this is still an extreme example, and I wouldn't write code
> like this:
>
> Obviously, if a is a _Bool, "a++" should be replaced with "a = true",
> and "a--" should be replaced with "a = !a"
>
> However, the fact that writing "a++" and "a--" is allowed gives Bart a
> point, IMO.
>

Bart's "point" was that _Bool is difficult to understand, unpredictable,
and varies between toolchains. He is wrong in almost all of that. (The
one thing that is correct is that the size of _Bool is
implementation-dependent - it is not necessarily 1.)

If you want to make the point that C's _Bool is not quite the ideal way
to have booleans in a programming language, then I'd agree - C++'s
version is better in several ways. But it is the best that could be
done in an addition to the C language, and the result is an extremely
useful type that C programmers use regularly.

>>
>> The logical and relational operators in C evaluate to "int", values 0 or
>> 1, preceding the introduction of _Bool to the language.
>>
>> The fact that you personally get confused about _Bool and don't
>> understand what it is and how it is defined, does not mean that it is
>> unclear, confusing, imprecise, or that anyone else fails to comprehend
>> it.
>>
>> However, now you know the rules that apply even when doing something as
>> deliberately unrealistic and pointless as incrementing or decrementing a
>> boolean variable.  So you can no longer claim that you don't understand
>> it, or are not sure what is going on, and can now happily make use of
>> this extremely useful type.
>>
>
> One might argue that the fact that the rules explain the result do not
> make the rules right.

You could argue that the rules are not the best choice if designing a
programming language from scratch, and including a boolean type at the
beginning. There's a lot about the rules of C that people disagree with
(though they will disagree about what they disagree with). However, C
is the language defined by the standards - it works well for a lot of
purposes. _Bool fits that perfectly.

On 05/02/2022 19:29, Richard Damon wrote:
> On 2/5/22 12:57 PM, Bart wrote:
>>
>> It doesn't explain the behaviour of MSVC [19.28.29337 for x64], which
>> outputs all zeros. Maybe another non-conforming one?
>
> Could the code have been compiled as C++, it uses different rules.
>
> If I remember right, in C++ if x is a bool, then x-- is defined to set x
> false and return the previous value of x, a test and clear instruction.

As far as I can tell, pre- and post-decrement of booleans have never
been allowed in C++. Pre- and post-increment give "true", matching C.

This is from C++14 (since I happen to have it open) 5.2.6p2 :

"""
The operand of postfix -- is decremented analogously to the postfix ++
operator, except that the operand shall not be of type bool.
"""

It says the same thing about pre-decrement. Both pre- and
post-increment were deprecated, and removed in C++17.

I think perhaps for his MSVC test, Bart used "BOOL", which is one of the
Windows API's specific types made for C90, and is a typedef for "int".

On 05/02/2022 19:46, James Kuyper wrote:

> The other feature is that you can declare a function parameter as follows:
>
> double limited(float [static 36]);
>
> "If the keyword static also appears within the [ and ] of the array type
> derivation, then for each call to the function, the value of the
> corresponding actual argument shall provide access to the first element
> of an array with at least as many elements as specified by the size
> expression." (7.5.3p7).
>
> Violating this "shall" has undefined behavior (4p2), which doesn't sound
> like much of an advantage. However, that also allows implementations to
> warn you with a diagnostic, if they can determine that your code might
> violate that requirement. If they can determine that it will
> unconditionally violate that requirement, they can even reject the
> program at compile time. It's that non-mandatory diagnostic that I
> consider valuable. It cannot, unfortunately, be made mandatory, because
> in many cases it's difficult, and often even impossible, to determine at
> compile time whether a piece of code will violate that requirement. But
> when it can be determined, I consider that a very valuable warning. YMMV.
>

This would also mean that :

double limited(float [static 1]);

is equivalent to :

double limited(float *);

except that you may not pass a null pointer to a call in the first case.
Again, this gives the compiler a chance to do some more helpful
diagnostics (as well as documenting requirement in the code).

On 06/02/2022 14:15, David Brown wrote:
> On 05/02/2022 19:29, Richard Damon wrote:
>> On 2/5/22 12:57 PM, Bart wrote:
>>>
>>> It doesn't explain the behaviour of MSVC [19.28.29337 for x64], which
>>> outputs all zeros. Maybe another non-conforming one?
>>
>> Could the code have been compiled as C++, it uses different rules.
>>
>> If I remember right, in C++ if x is a bool, then x-- is defined to set x
>> false and return the previous value of x, a test and clear instruction.
>
> As far as I can tell, pre- and post-decrement of booleans have never
> been allowed in C++. Pre- and post-increment give "true", matching C.
>
>
> This is from C++14 (since I happen to have it open) 5.2.6p2 :
>
> """
> The operand of postfix -- is decremented analogously to the postfix ++
> operator, except that the operand shall not be of type bool.
> """
>
> It says the same thing about pre-decrement. Both pre- and
> post-increment were deprecated, and removed in C++17.
>
>
> I think perhaps for his MSVC test, Bart used "BOOL", which is one of the
> Windows API's specific types made for C90, and is a typedef for "int".

All tests used _Bool.

BOOL, defined as int, would have given results of 0 1 2 3 ... for ++a,
and 0 -1 -2 -3 ... for --a.

(I don't know how to put MSVC into C mode, but I suspect it already is.
A couple of 1000-line C programs, with .c extensions, that fail with
g++, pass with gcc and MSVC.

Also, while MSVC compiles a C++ hello-world program when it has a .cpp
extension, it fails dramatically if I change to a .c extension. All my
tests were .c files.)

On 2/6/2022 6:11 AM, James Kuyper wrote:
> On 2/5/22 17:18, Manfred wrote:
>> On 2/5/22 5:27 PM, David Brown wrote:
> ...
>> There is no reason why a boolean type should behave as shown with ++ and --.
>>
>> The fact that this is the result of an implicit round trip to and from
>> 'int' shows that _Bool is to some extent still intermingled with 'int',
>> despite the intention of making a true boolean type to get rid of the
>> traditional use of 'int' for this purpose.
>
> Well, what would you expect when applying arithmetic operators to
> boolean values? If I weren't familiar with the C standard's
> specifications for such things, I wouldn't have any expectations at all
> - you shouldn't use such operators on boolean values.

Exactly, and I add that from the same perspective it would be better if
arithmetic operators on boolean types weren't allowed by the language.
Allowing them might open some niche corner use case, but at the same
time it exposes the language to a critique about consistency like
Bart's, which, as I said, has in fact some grounds.

>
> ...
>>> However, now you know the rules that apply even when doing something as
>>> deliberately unrealistic and pointless as incrementing or decrementing a
>>> boolean variable. So you can no longer claim that you don't understand
>>> it, or are not sure what is going on, and can now happily make use of
>>> this extremely useful type.
>>>
>>
>> One might argue that the fact that the rules explain the result do not
>> make the rules right.
>
> The committee is the ultimate authority with respect to the C standard -
> there's no other authority against which their decisions can be compared
> for correctness. You can say it's poorly designed, internally
> inconsistent, inconsistent with existing architectures or other computer
> languages, etc.; but to say it's wrong implies a standard of correctness
> it can be compared with, and there is none. In C, the ++ operator does
> what the C standard says it should do - you can decide whether or not
> what it does is useful for you, but there's no basis for saying that
> what the standard says about it is wrong.

While I was writing that last sentence I've been wondering about the
word "right" because of the meaning you reply at.
I meant "right" as "well done", "smart", "well designed" etc.
I think it was clear because the sentence is about "rules": rules are,
by definition, mandatory, hence your meaning for "correctness" is
implicit in the definition of "rule".
Therefore, arguing about whether a rule is right or wrong is about the
rule being well designed, thought of, chosen or not.

In a sense, it's like with law in civil life: you have to abide to all
laws, and it is right to do so - but at the same time one is allowed to
say if some law, in their opinion, is not right, just or fair. The
former part is about cohabitation in a civil society, the latter is
about (the right for) critical thought.

Lots of "right"'s here...
(I like the English language, even if I am not a native English speaker,
however I think one of its weaknesses is the more limited vocabulary
compared to other languages)

Bart <bc@freeuk.com> writes:
[...]
> (I don't know how to put MSVC into C mode, but I suspect it already
> is. A couple of 1000-line C programs, with .c extensions, that fail
> with g++, pass with gcc and MSVC.

You can confirm this by using "class" as an identifier, or, if you want
to be more explicit, something like this:

#ifdef __cplusplus
#error "Compiled as C++"
#endif

> Also, while MSVC compiles a C++ hello-world program when it has a .cpp
> extension, it fails dramatically if I change to a .c extension. All my
> tests were .c files.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 03/02/2022 22:48, Mateusz Viste wrote:
> 2022-02-03 at 22:28 +0000, Vir Campestris wrote:
>> I use bool all the time; why would you use anything else? It's a type
>> that holds 2 values, and the compiler can pick what to use for your
>> processor. It might be a bit mask, or a 64 bit word. It might even
>> vary with your optimisation settings.
>
> Can you tell what advantage it has over using, say, int_fast8_t?
>

It depends on your machine.

I've worked on machines where to read a byte from memory involves
reading a word, shifting it, then anding with 255.

Writing one back means shifting the byte in a register, reading a word
from memory, ANDing out the old value, ORing the new one, then writing
back the word.

I've also worked on ones, albeit not with C, where a character isn't 8
bits but only 6.

bool lets the compiler pick a type where the architecture can store 2
values easily.

int_fast8_t is only convenient on machines that have hardware byte
support. OK, that's most of them, but by no means all.

Andy

2022-02-06 at 22:08 +0000, Vir Campestris wrote:
> bool lets the compiler pick a type where the architecture can store 2
> values easily.
>
> int_fast8_t is only convenient on machines that have hardware byte
> support. OK, that's most of them, but by no means all.

int_fast8_t is convenient on machines that have hardware support for
anything that is at least 8 bits large. I imagine that on a machine
like the one you describe (no bytes, words only) int_fast8_t would be a
word.

Mateusz

2022-02-07 at 09:11 +0100, Mateusz Viste wrote:
> 2022-02-06 at 22:08 +0000, Vir Campestris wrote:
> > bool lets the compiler pick a type where the architecture can store
> > 2 values easily.
> >
> > int_fast8_t is only convenient on machines that have hardware byte
> > support. OK, that's most of them, but by no means all.
>
> int_fast8_t is convenient on machines that have hardware support for
> anything that is at least 8 bits large.
^^
(should have been "16" obviously) :)

Mateusz