Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> If you want to make C a safer language, one obvious thing is to disallow
> using “=” in the middle of an expression. Instead of returning the value
> of the expression, have it return void. Or just disallow it syntactically
> altogether.

Possibly you’re suggesting that with hindsight, C should have always
worked like that. If it had been then we’d have fewer bugs and the
status quo bias would mean little or no pressure to allow assignment
expressions in a wider set of contexts.

Alternatively, you’re suggesting it as a future change. That leads to a
couple of questions. First are you envisaging it as a new rule in a
future version of standard C, or a new language which differs from C in
this one detail (call it C prime, perhaps)? The second is how you
envisage it being deployed, given the huge body of code that depends
(wisely or not) on the existing rules, and would need to be modified to
follow the new rules without any change to its meaning.

--
https://www.greenend.org.uk/rjk/

On 11/02/2024 17:05, David Brown wrote:
> On 11/02/2024 17:55, Malcolm McLean wrote:
>> On 11/02/2024 02:00, Keith Thompson wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>> On Sat, 10 Feb 2024 17:34:51 -0800, Keith Thompson wrote:
>>>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>>> On Sun, 11 Feb 2024 01:08:51 +0000, Ben Bacarisse wrote:
>>> [...]
>>>>>>> The type of c == d is int, but the value will be either 0 or 1.
>>>>>>
>>>>>> That is the only kind of “boolean” C has.
>>>>>
>>>>> No it isn't.  C99 added _Bool, which can be called bool if you include
>>>>> <stdbool.h>.  C23 (not yet released) will make bool a keyword, with
>>>>> _Bool as an alternative spelling.
>>>>>
>>>>> But the equality and relational operators still yield results of type
>>>>> int with value 0 or 1.
>>>>
>>>> All just new, different names for what I said: still the only kind of
>>>> “boolean” C has.
>>>
>>> I can imagine that you're trying to express something that's correct,
>>> but I honestly have no idea what it might be.
>>>
>>> C has a boolean type, called "_Bool" or "bool", added in C99.  _Bool is
>>> a distinct type, not the same as or compatible with any other type.
>>>
>>> Equality and relational operators yield results of type int, not _Bool.
>>>
>>> An expression of any scalar type (which includes integer,
>>> floating-point, and pointer types) can be used as a condition.
>>>
>>> Assuming you agree with all that, I have no idea what you mean by "the
>>> only kind of “boolean” C has".
>>>
>> Other lanaguages were designed with a "boolean" type which had special
>> rules (bool + bool would either be disallowed or yield 1
>>   if both were true), and was intended to be used wherever a value was
>> logically either true or false. C didn't and used a int with just
>> happened to be 1 or 0 for this purpose, and whilst booleans have now
>> been added, the old system cannot be entirely eliminated and remains.
>
> Yes, we all know that.  (Well, everyone who has learned a bit of C99
> knows that.)  It's very difficult to change things in a language that
> has as much use as C - changing the type of the value of expressions
> like "x == y" would have been a breaking change.  When C++ was forked
> from C, it was able to make such breaking changes - thus "x == y" gives
> a bool in C++.  But for C, it was too late.
>
So in fact it should be pretty obvious what LDO is getting at.

>> You can achieve most of the benefits of a boolean type by aliasing
>> "int' to "bool" and defining "true" and "false", and a lot of C
>> installations do exactly this.
>>
>
> No, you can't.  That gives you the worst of all worlds.
>
> Use type "bool" when you want a boolean.  It is /not/ the same as an
> int, or an enumerated type, or an unsigned char, or anything else that
> might be used as a "home-made boolean" - it has important additional
> characteristics.  "Home-made boolean" types might be considered useful
> in C90, but not in C99.  Recommending them now is bad advice, and
> recommending that you do so using the names "bool", "true" and "false"
> which conflict with C's real boolean type is extraordinarily silly.
>
I used to say "bool breaks libraries" and this is exactly the problem. A
simple typedef bool "bool" to "int" and definiing "true" and "false"
creates problems because there are no namespaces, you export the
symbols, and either they clash or they create mismash of subtly
different Boolean types. So I am not recommending it in user code.
However I am saying that it does achieve most of the benefits of having
a boolean type, and therefore people who do this are not entirely
stupid. But I'm talking about the C installation, so normally the person
who provides the compiler, not the user code.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Em 2/8/2024 9:39 PM, Lawrence D'Oliveiro escreveu:
> If you want to make C a safer language, one obvious thing is to disallow
> using “=” in the middle of an expression. Instead of returning the value
> of the expression, have it return void. Or just disallow it syntactically
> altogether.
>
> Sure, you may still want to write something like
>
> a = b = c;
>
> but Python has found a way to allow that, without saying that “b = c” has
> to return a value.

The approach I am doing in cake (https://github.com/thradams/cake) is
require "bool" in conditional expression.

if (expression) ...
expression must be bool type.

BUT...
In C, a == b are of type int.

So

if (a == b) ...

would emit an warning.

To deal with this problem I have two "types" in expressions.

One type represents the type used by the language (int in this case) the
second type is something like "working as bool" .
So the expression a == b has the "type int" working as "bool"

void f(bool b);
f(2); //I have a warning
f(2 == 2); //but not here

I want to make an exception for pointer

if (pointer) ...

because this is very common.

The other situation where two types are used are enumerators
enum E {A }
In C A is "int" but the second type is "working as enum E".
This allows me to check usage of different enumerators.

In this case...
if (a = b) is naturally an warning except if a and b are booleans but
even in this case I may add an warning.

Em 2/11/2024 4:12 PM, Thiago Adams escreveu:
> Em 2/8/2024 9:39 PM, Lawrence D'Oliveiro escreveu:
>> If you want to make C a safer language, one obvious thing is to disallow
>> using “=” in the middle of an expression. Instead of returning the value
>> of the expression, have it return void. Or just disallow it syntactically
>> altogether.
>>
>> Sure, you may still want to write something like
>>
>>      a = b = c;
>>
>> but Python has found a way to allow that, without saying that “b = c” has
>> to return a value.
>
> The approach I am doing in cake (https://github.com/thradams/cake) is
> require "bool" in conditional expression.
>
> if (expression) ...
> expression must be bool type.
>
> BUT...
> In C, a == b are of type int.
>
> So
>
> if (a == b) ...
>
> would emit an warning.
>
> To deal with this problem I have two "types" in expressions.

forgot to include literal char.
The type of 'A' is int.. however the second type is "character"

This is to allow extra checks.

David Brown <david.brown@hesbynett.no> writes:
> On 11/02/2024 02:08, Ben Bacarisse wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> On Sat, 10 Feb 2024 16:58:01 +0100, David Brown wrote:
>>>> It says "Assignment operators shall not be used in expressions which
>>>> return Boolean values", at least in my copy of MISRA 1998.
>>>
>>> One thing with that wording, it would disallow chained assignments in such
>>> innocuous cases as
>>>
>>> a = b = c == d;
>>>
>>> since, after all, the expression is returning a boolean.
>> The type of c == d is int, but the value will be either 0 or 1. Is
>> that
>> what you mean by an expression "returning a boolean" -- an expression of
>> type in with either 0 or 1 as the value?
>
> I think that is what MISRA means when they talk about "essentially
> boolean" - but as I mentioned before, they don't define the term at
> all. (MISRA 2012 supports C99, and also appears to consider _Bool as
> "essentially boolean", despite not defining it.)

I'll note that the requirement "Assignment operators shall not be used
in expressions which return Boolean values" doesn't use the (undefined)
term "essentially Boolean".

If it's intended to refer to "essentially Boolean" values, and if it
means what you suggest, then the guideline would permit this:

char c = ...;
int uc;
if (uc = isupper(c)) ...

since isupper() is specified to return zero or non-zero, not zero or
one. (It would be disallowed by the later version of MISRA which bans
any use of the result of an assignment expression.)

The only way the term "boolean" or "essentially Boolean" makes sense is
if it refers to *conditions*.

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

On Sun, 11 Feb 2024 16:12:25 -0300, Thiago Adams wrote:

> The approach I am doing in cake (https://github.com/thradams/cake) is
> require "bool" in conditional expression.
>
> if (expression) ...
> expression must be bool type.
>
> BUT...
> In C, a == b are of type int.

But boolean is a subtype of int anyway, so what’s the harm in redefining
conditional expressions to return bool instead?

> One type represents the type used by the language (int in this case) the
> second type is something like "working as bool" .
> So the expression a == b has the "type int" working as "bool"

If bool is a subtype of (unsigned?) int, then you are allowed to pass bool
where int is wanted, but not the other way round.

> The other situation where two types are used are enumerators
> enum E {A }
> In C A is "int" but the second type is "working as enum E".
> This allows me to check usage of different enumerators.

Again, enums can be considered to be subtypes of int (or even unsigned
int). You can think of bool as a special case of a predefined enum.

On Sun, 11 Feb 2024 13:57:23 +0100, David Brown wrote:

> You are attributing a level of sophistication and forethought to the
> MISRA authors that they simply did not have.

Fair enough. ;)

On Sat, 10 Feb 2024 21:37:26 -0800, Keith Thompson wrote:

> _Bool is a distinct type. Equality and relational operators yield
> results of type int, which is not type _Bool.

There is no place where one type can be used, but the other cannot.

On Sun, 11 Feb 2024 18:05:08 +0100, David Brown wrote:

> Use type "bool" when you want a boolean. It is /not/ the same as an
> int ...

You seem to be saying that something like

bool a = b == c;

should not be allowed.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sun, 11 Feb 2024 16:12:25 -0300, Thiago Adams wrote:
>
>> The approach I am doing in cake (https://github.com/thradams/cake) is
>> require "bool" in conditional expression.
>>
>> if (expression) ...
>> expression must be bool type.
>>
>> BUT...
>> In C, a == b are of type int.
>
> But boolean is a subtype of int anyway, so what’s the harm in redefining
> conditional expressions to return bool instead?

No, boolean (by which I presume you mean _Bool / bool) is not a
"subtype" of int. C doesn't have anything called "subtypes". _Bool and
int are distinct types, just as short and int are distinct types.

>> One type represents the type used by the language (int in this case) the
>> second type is something like "working as bool" .
>> So the expression a == b has the "type int" working as "bool"
>
> If bool is a subtype of (unsigned?) int, then you are allowed to pass bool
> where int is wanted, but not the other way round.

I don't know what you mean by "subtype". There are implicit conversions
in both directions between _Bool and int, which apply to assignment,
parameter passing, etc. Conversions to _Bool can lose information.

>> The other situation where two types are used are enumerators
>> enum E {A }
>> In C A is "int" but the second type is "working as enum E".
>> This allows me to check usage of different enumerators.
>
> Again, enums can be considered to be subtypes of int (or even unsigned
> int). You can think of bool as a special case of a predefined enum.

No, enum types are also distinct types, and bool is not an enum type
(though it has some resemblance to enum types). (Enumerators are of
type int.)

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

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sat, 10 Feb 2024 21:37:26 -0800, Keith Thompson wrote:
>> _Bool is a distinct type. Equality and relational operators yield
>> results of type int, which is not type _Bool.
>
> There is no place where one type can be used, but the other cannot.

Incorrect.

int main(void) {
_Bool b;
int i;
_Bool *ptr = &i;
// constraint violation because _Bool and int are not compatible
}

Do you understand that int and _Bool are distinct and incompatible
types, and that neither is a "subtype" of the other?

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

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Sat, 10 Feb 2024 21:37:26 -0800, Keith Thompson wrote:
>>> _Bool is a distinct type. Equality and relational operators yield
>>> results of type int, which is not type _Bool.
>>
>> There is no place where one type can be used, but the other cannot.
>
> Incorrect.
>
> int main(void) {
> _Bool b;
> int i;
> _Bool *ptr = &i;
> // constraint violation because _Bool and int are not compatible
> }
>
> Do you understand that int and _Bool are distinct and incompatible
> types, and that neither is a "subtype" of the other?

Oh, and conversion from any scalar type to _Bool yields either (_Bool)0
or (_Bool)1, a major difference between _Bool and all other scalar
types.

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

On Sun, 11 Feb 2024 19:12:35 -0800, Keith Thompson wrote:

> int main(void) {
> _Bool b;
> int i;
> _Bool *ptr = &i;
> // constraint violation because _Bool and int are not compatible
> }
>
> Do you understand that int and _Bool are distinct and incompatible
> types ...

No more so than, say, int and short int.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sun, 11 Feb 2024 19:12:35 -0800, Keith Thompson wrote:
>
>> int main(void) {
>> _Bool b;
>> int i;
>> _Bool *ptr = &i;
>> // constraint violation because _Bool and int are not compatible
>> }
>>
>> Do you understand that int and _Bool are distinct and incompatible
>> types ...
>
> No more so than, say, int and short int.

Correct. int, short int, and _Bool are three distinct and incompatible
types.

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

On 12/02/2024 04:47, Lawrence D'Oliveiro wrote:
> On Sun, 11 Feb 2024 19:12:35 -0800, Keith Thompson wrote:
>
>> int main(void) {
>> _Bool b;
>> int i;
>> _Bool *ptr = &i;
>> // constraint violation because _Bool and int are not compatible
>> }
>>
>> Do you understand that int and _Bool are distinct and incompatible
>> types ...
>
> No more so than, say, int and short int.

These are indeed distinct and incompatible types. That applies even if
they happen to be the same size.

Do you know what "incompatible types" are, and what they mean? Do you
realise that they cannot be swapped around as you suggest?

As an example, look at the code generated for this with gcc for the
msp430 (a 16-bit target, where "int" and "short int" are the same size,
and where the assembly is simple enough to understand).

<https://godbolt.org/z/81cE5YThz>

int sizeof_short = sizeof(short int);
int sizeof_int = sizeof(int);

int foo1(int * p, short int * q) {
*p = 10;
*q += 1;
return *p;
}

int foo2(int * p, int * q) {
*p = 10;
*q += 1;
return *p;
}

foo1:
MOV.W #10, @R12
ADD.W #1, @R13
MOV.B #10, R12
RET
foo2:
MOV.W #10, @R12
ADD.W #1, @R13
MOV.W @R12, R12
RET
sizeof_int:
.short 2
sizeof_short:
.short 2

The compiler knows that in "foo1", "p" and "q" cannot point to the same
thing, because they are incompatible types. For "foo2", when swapping
"short int" for "int", the code is less efficient - it needs an extra
read from memory.

On 12/02/2024 04:34, Keith Thompson wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> On Sat, 10 Feb 2024 21:37:26 -0800, Keith Thompson wrote:
>>>> _Bool is a distinct type. Equality and relational operators yield
>>>> results of type int, which is not type _Bool.
>>>
>>> There is no place where one type can be used, but the other cannot.
>>
>> Incorrect.
>>
>> int main(void) {
>> _Bool b;
>> int i;
>> _Bool *ptr = &i;
>> // constraint violation because _Bool and int are not compatible
>> }
>>
>> Do you understand that int and _Bool are distinct and incompatible
>> types, and that neither is a "subtype" of the other?
>
> Oh, and conversion from any scalar type to _Bool yields either (_Bool)0
> or (_Bool)1, a major difference between _Bool and all other scalar
> types.
>

Absolutely. There is a /massive/ difference between:

int * p;

_Bool b = p;

and

int x = p;

On 12/02/2024 11:26, David Brown wrote:
> On 12/02/2024 04:34, Keith Thompson wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>> On Sat, 10 Feb 2024 21:37:26 -0800, Keith Thompson wrote:
>>>>> _Bool is a distinct type.  Equality and relational operators yield
>>>>> results of type int, which is not type _Bool.
>>>>
>>>> There is no place where one type can be used, but the other cannot.
>>>
>>> Incorrect.
>>>
>>> int main(void) {
>>>      _Bool b;
>>>      int i;
>>>      _Bool *ptr = &i;
>>>      // constraint violation because _Bool and int are not compatible
>>> }
>>>
>>> Do you understand that int and _Bool are distinct and incompatible
>>> types, and that neither is a "subtype" of the other?
>>
>> Oh, and conversion from any scalar type to _Bool yields either (_Bool)0
>> or (_Bool)1, a major difference between _Bool and all other scalar
>> types.
>>
>
> Absolutely.  There is a /massive/ difference between:
>
>     int * p;

I assume the * is a typo?

>     _Bool b = p;
>
> and
>
>     int x = p;
>
>

On 11/02/2024 19:00, Malcolm McLean wrote:
> On 11/02/2024 17:05, David Brown wrote:
>> On 11/02/2024 17:55, Malcolm McLean wrote:
>>> On 11/02/2024 02:00, Keith Thompson wrote:
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>> On Sat, 10 Feb 2024 17:34:51 -0800, Keith Thompson wrote:
>>>>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>>>> On Sun, 11 Feb 2024 01:08:51 +0000, Ben Bacarisse wrote:
>>>> [...]
>>>>>>>> The type of c == d is int, but the value will be either 0 or 1.
>>>>>>>
>>>>>>> That is the only kind of “boolean” C has.
>>>>>>
>>>>>> No it isn't.  C99 added _Bool, which can be called bool if you
>>>>>> include
>>>>>> <stdbool.h>.  C23 (not yet released) will make bool a keyword, with
>>>>>> _Bool as an alternative spelling.
>>>>>>
>>>>>> But the equality and relational operators still yield results of type
>>>>>> int with value 0 or 1.
>>>>>
>>>>> All just new, different names for what I said: still the only kind of
>>>>> “boolean” C has.
>>>>
>>>> I can imagine that you're trying to express something that's correct,
>>>> but I honestly have no idea what it might be.
>>>>
>>>> C has a boolean type, called "_Bool" or "bool", added in C99.  _Bool is
>>>> a distinct type, not the same as or compatible with any other type.
>>>>
>>>> Equality and relational operators yield results of type int, not _Bool.
>>>>
>>>> An expression of any scalar type (which includes integer,
>>>> floating-point, and pointer types) can be used as a condition.
>>>>
>>>> Assuming you agree with all that, I have no idea what you mean by "the
>>>> only kind of “boolean” C has".
>>>>
>>> Other lanaguages were designed with a "boolean" type which had
>>> special rules (bool + bool would either be disallowed or yield 1
>>>   if both were true), and was intended to be used wherever a value
>>> was logically either true or false. C didn't and used a int with just
>>> happened to be 1 or 0 for this purpose, and whilst booleans have now
>>> been added, the old system cannot be entirely eliminated and remains.
>>
>> Yes, we all know that.  (Well, everyone who has learned a bit of C99
>> knows that.)  It's very difficult to change things in a language that
>> has as much use as C - changing the type of the value of expressions
>> like "x == y" would have been a breaking change.  When C++ was forked
>> from C, it was able to make such breaking changes - thus "x == y"
>> gives a bool in C++.  But for C, it was too late.
>>
> So in fact it should be pretty obvious what LDO is getting at.

I agree - it is fairly obvious what he means. It is equally obvious
that he is wrong.

>
>>> You can achieve most of the benefits of a boolean type by aliasing
>>> "int' to "bool" and defining "true" and "false", and a lot of C
>>> installations do exactly this.
>>>
>>
>> No, you can't.  That gives you the worst of all worlds.
>>
>> Use type "bool" when you want a boolean.  It is /not/ the same as an
>> int, or an enumerated type, or an unsigned char, or anything else that
>> might be used as a "home-made boolean" - it has important additional
>> characteristics.  "Home-made boolean" types might be considered useful
>> in C90, but not in C99.  Recommending them now is bad advice, and
>> recommending that you do so using the names "bool", "true" and "false"
>> which conflict with C's real boolean type is extraordinarily silly.
>>
> I used to say "bool breaks libraries" and this is exactly the problem.

That is why C99 calls the type "_Bool", and you need to include
<stdbool.h> to get the nicer name "bool". Now with C23, the C standards
committee feel confident that the proportion of code that used "bool"
for their own types is small enough that it is safe to make "bool",
"true" and "false" keywords.

And it is why it is insane to suggest that it is a good idea to make
your own pseudo-boolean type in C and call it "bool". It was a
questionable idea in the late nineties when C99 was known to be coming
soon, a bad idea in the early naughties when it had been published and
compiler support was gaining, and is certainly not an acceptable idea now.

> A
> simple typedef bool "bool" to "int" and definiing "true" and "false"
> creates problems because there are no namespaces, you export the
> symbols, and either they clash or they create mismash of subtly
> different Boolean types.

Correct.

> So I am not recommending it in user code.

Then what were you doing when you wrote this?

"""
You can achieve most of the benefits of a boolean type by aliasing
"int' to "bool" and defining "true" and "false", and a lot of C
installations do exactly this.
"""

> However I am saying that it does achieve most of the benefits of having
> a boolean type, and therefore people who do this are not entirely
> stupid. But I'm talking about the C installation, so normally the person
> who provides the compiler, not the user code.
>

And what is a "C installation" ? Do you mean a "C /implementation/" ?
Do you mean your own modification to headers or libraries after you have
installed a toolchain? Do you mean a company's standard additional
libraries?

Or do you mean that C implementations simply put "typedef int bool;" as
their <stdbool.h> implementation? That would, of course, be utter nonsense.

On 12/02/2024 02:17, Lawrence D'Oliveiro wrote:
> On Sun, 11 Feb 2024 18:05:08 +0100, David Brown wrote:
>
>> Use type "bool" when you want a boolean. It is /not/ the same as an
>> int ...
>
> You seem to be saying that something like
>
> bool a = b == c;
>
> should not be allowed.

No, I don't seem to be saying that at all. An "int" value can
implicitly be converted to a _Bool.

That does not mean that "int" and "_Bool" are the same thing.

On 11/02/2024 22:15, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 11/02/2024 02:08, Ben Bacarisse wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>> On Sat, 10 Feb 2024 16:58:01 +0100, David Brown wrote:
>>>>> It says "Assignment operators shall not be used in expressions which
>>>>> return Boolean values", at least in my copy of MISRA 1998.
>>>>
>>>> One thing with that wording, it would disallow chained assignments in such
>>>> innocuous cases as
>>>>
>>>> a = b = c == d;
>>>>
>>>> since, after all, the expression is returning a boolean.
>>> The type of c == d is int, but the value will be either 0 or 1. Is
>>> that
>>> what you mean by an expression "returning a boolean" -- an expression of
>>> type in with either 0 or 1 as the value?
>>
>> I think that is what MISRA means when they talk about "essentially
>> boolean" - but as I mentioned before, they don't define the term at
>> all. (MISRA 2012 supports C99, and also appears to consider _Bool as
>> "essentially boolean", despite not defining it.)
>
> I'll note that the requirement "Assignment operators shall not be used
> in expressions which return Boolean values" doesn't use the (undefined)
> term "essentially Boolean".

Correct - the term "essentially boolean" is from MISRA 2012, while the
rule you quote there is from MISRA 1998. There are several versions of
MISRA C (1998, 2004, 2012, 2016, and 2023) - I have been referring to
1998 and 2012, since these are the versions I have available. (I should
probably buy a copy of the latest version some time.)

The "essential type" system is in MISRA 2012, but not MISRA 1998. (I
don't know about 2004.)

I would say that MISRA 1998 should also define the term "Boolean value",
but it does not.

>
> If it's intended to refer to "essentially Boolean" values, and if it
> means what you suggest, then the guideline would permit this:
>
> char c = ...;
> int uc;
> if (uc = isupper(c)) ...
>
> since isupper() is specified to return zero or non-zero, not zero or
> one. (It would be disallowed by the later version of MISRA which bans
> any use of the result of an assignment expression.)
>
> The only way the term "boolean" or "essentially Boolean" makes sense is
> if it refers to *conditions*.
>

I think you are searching for consistency and meaning where there is
none to be found. IMHO the standard is vague and woolly about this kind
of thing, and it is extremely simple to think of examples that don't fit
neatly with their rules.

MISRA 2012 is bad, but less bad than MISRA 1998. Perhaps by MISRA 2023
(which is the third revision of MISRA 2012), they've done better.

On 12/02/2024 12:38, bart wrote:
> On 12/02/2024 11:26, David Brown wrote:
>> On 12/02/2024 04:34, Keith Thompson wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>> On Sat, 10 Feb 2024 21:37:26 -0800, Keith Thompson wrote:
>>>>>> _Bool is a distinct type.  Equality and relational operators yield
>>>>>> results of type int, which is not type _Bool.
>>>>>
>>>>> There is no place where one type can be used, but the other cannot.
>>>>
>>>> Incorrect.
>>>>
>>>> int main(void) {
>>>>      _Bool b;
>>>>      int i;
>>>>      _Bool *ptr = &i;
>>>>      // constraint violation because _Bool and int are not compatible
>>>> }
>>>>
>>>> Do you understand that int and _Bool are distinct and incompatible
>>>> types, and that neither is a "subtype" of the other?
>>>
>>> Oh, and conversion from any scalar type to _Bool yields either (_Bool)0
>>> or (_Bool)1, a major difference between _Bool and all other scalar
>>> types.
>>>
>>
>> Absolutely.  There is a /massive/ difference between:
>>
>>      int * p;
>
> I assume the * is a typo?

No.

>
>>      _Bool b = p;

This is equivalent to "b = (p != NULL);" and does not elicit a warning
from gcc (-Wall -Wextra -Wpedantic -std=C11).

(You might feel that there /should/ be a warning about it - that's
another matter. I'm saying what gcc does here, not what I think it
should do.)

>>
>> and
>>
>>      int x = p;
>>

This will set "x" to an integer value based on the pointer's address.
It is almost certainly not something the programmer wanted, and elicits
a warning from gcc even without any options.

The point is, "_Bool" and "int" are not only different in theory (as
Keith has said several times, they are different incompatible types),
but they are different in practice.

(I don't know if your compiler has support for _Bool at all.)

On 12/02/2024 13:36, David Brown wrote:
> On 12/02/2024 12:38, bart wrote:
>> On 12/02/2024 11:26, David Brown wrote:

>>> Absolutely.  There is a /massive/ difference between:
>>>
>>>      int * p;
>>
>> I assume the * is a typo?
>
> No.
>
>>
>>>      _Bool b = p;
>
> This is equivalent to "b = (p != NULL);" and does not elicit a warning
> from gcc (-Wall -Wextra -Wpedantic -std=C11).
>
> (You might feel that there /should/ be a warning about it - that's
> another matter.  I'm saying what gcc does here, not what I think it
> should do.)
>
>>>
>>> and
>>>
>>>      int x = p;
>>>
>
> This will set "x" to an integer value based on the pointer's address. It
> is almost certainly not something the programmer wanted, and elicits a
> warning from gcc even without any options.

OK, at least one of them was wrong! I saw the warning for this one from
gcc; my compiler rejects both assignments.

>
> The point is, "_Bool" and "int" are not only different in theory (as
> Keith has said several times, they are different incompatible types),
> but they are different in practice.
>
> (I don't know if your compiler has support for _Bool at all.)

My C compiler has a _Bool type but it is just an alias for 'char'. (I
think done when 'char' was an alias for 'unsigned char', I later changed
it to 'signed char'.)

So it doesn't have any special properties; assigning p to it is an error
(it will need !!p), and assigning *p will copy the bottom 8 bits.

(However, if I do the same test in my systems language, there it works
as expected:

ref void p:=nil, q:=&p
bool b:=p, c:=q
println b, c, int(c)

It prints 'False True 1', which was a surprise as I must have forgotten
I'd done that support. I never use 'bool', it's more of an internal
type. But it means I could port some of this to the C compiler.)

On 12/02/2024 14:57, bart wrote:
> On 12/02/2024 13:36, David Brown wrote:
>> On 12/02/2024 12:38, bart wrote:
>>> On 12/02/2024 11:26, David Brown wrote:
>
>>>> Absolutely.  There is a /massive/ difference between:
>>>>
>>>>      int * p;
>>>
>>> I assume the * is a typo?
>>
>> No.
>>
>>>
>>>>      _Bool b = p;
>>
>> This is equivalent to "b = (p != NULL);" and does not elicit a warning
>> from gcc (-Wall -Wextra -Wpedantic -std=C11).
>>
>> (You might feel that there /should/ be a warning about it - that's
>> another matter.  I'm saying what gcc does here, not what I think it
>> should do.)
>>
>>>>
>>>> and
>>>>
>>>>      int x = p;
>>>>
>>
>> This will set "x" to an integer value based on the pointer's address.
>> It is almost certainly not something the programmer wanted, and
>> elicits a warning from gcc even without any options.
>
>
> OK, at least one of them was wrong! I saw the warning for this one from
> gcc; my compiler rejects both assignments.
>

Conversions of a pointer to "int" or to "_Bool" are both allowed by the
C standards. So a conforming C compiler has to accept them and generate
appropriate code for them.

If the pointer's value cannot be represented in the target type when
converting to an integer type, then it is undefined behaviour - but the
compiler usually can't know that for sure at compile time. Thus it has
to generate code that accepts this and will work if the address happens
to be small enough. The compiler can, however, issue a warning that the
programmer is probably doing something silly.

Conversion of any scaler (including pointers) to _Bool is done by
comparison to 0. And since that is often a sensible thing to do, there
is no warning in gcc - it would give too many false positives.

>>
>> The point is, "_Bool" and "int" are not only different in theory (as
>> Keith has said several times, they are different incompatible types),
>> but they are different in practice.
>>
>> (I don't know if your compiler has support for _Bool at all.)
>
> My C compiler has a _Bool type but it is just an alias for 'char'. (I
> think done when 'char' was an alias for 'unsigned char', I later changed
> it to 'signed char'.)
>
> So it doesn't have any special properties; assigning p to it is an error
> (it will need !!p), and assigning *p will copy the bottom 8 bits.
>

You really should remove it, or fix it. Having a type that is called
_Bool but does not act like _Bool is likely to be confusing and unhelpful.

The key properties of _Bool are :

1. It is a standard /unsigned/ integer type, big enough to hold 0 or 1.

2. Conversion of any scaler to _Bool is done by comparison to 0, not by
truncation, and it can only ever have a value of 0 or 1. (The padding
bits can have any value.)

Since assignment is done by conversion, that also means that something
like "_Bool b = 2;" is implemented as "_Bool b = (2 != 0);", thus
setting "b" to 1.

> (However, if I do the same test in my systems language, there it works
> as expected:
>
>       ref void p:=nil, q:=&p
>       bool b:=p, c:=q
>       println b, c, int(c)
>
> It prints 'False True 1', which was a surprise as I must have forgotten
> I'd done that support. I never use 'bool', it's more of an internal
> type. But it means I could port some of this to the C compiler.)
>

I would recommend that your _Bool in C works as required by the C99
standards, or is removed entirely. I know you are not aiming for any
kind of strict conformance, but it's still not a good idea to have such
inconsistencies.

David Brown <david.brown@hesbynett.no> writes:
> On 12/02/2024 12:38, bart wrote:
>> On 12/02/2024 11:26, David Brown wrote:
>>> On 12/02/2024 04:34, Keith Thompson wrote:
>>>> Oh, and conversion from any scalar type to _Bool yields either (_Bool)0
>>>> or (_Bool)1, a major difference between _Bool and all other scalar
>>>> types.
>>>
>>> Absolutely.  There is a /massive/ difference between:
>>>
>>>      int * p;
>> I assume the * is a typo?
>
> No.
>
>>
>>>      _Bool b = p;
>
> This is equivalent to "b = (p != NULL);" and does not elicit a warning
> from gcc (-Wall -Wextra -Wpedantic -std=C11).
>
> (You might feel that there /should/ be a warning about it - that's
> another matter. I'm saying what gcc does here, not what I think it
> should do.)
>
>>> and
>>>
>>>      int x = p;
>>>
>
> This will set "x" to an integer value based on the pointer's
> address. It is almost certainly not something the programmer wanted,
> and elicits a warning from gcc even without any options.

This is a constraint violation. A compiler that doesn't reject it
*might* generate code that behaves as you suggest.

[...]

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

David Brown <david.brown@hesbynett.no> writes:
[...]
>>>> On 12/02/2024 11:26, David Brown wrote:
[...]
>>>>>      int * p;
[...]
>>>>>      _Bool b = p;
[...]
>>>>>      int x = p;
[...]
> Conversions of a pointer to "int" or to "_Bool" are both allowed by
> the C standards. So a conforming C compiler has to accept them and
> generate appropriate code for them.
>
> If the pointer's value cannot be represented in the target type when
> converting to an integer type, then it is undefined behaviour - but
> the compiler usually can't know that for sure at compile time. Thus
> it has to generate code that accepts this and will work if the address
> happens to be small enough. The compiler can, however, issue a
> warning that the programmer is probably doing something silly.
>
> Conversion of any scaler (including pointers) to _Bool is done by
> comparison to 0. And since that is often a sensible thing to do,
> there is no warning in gcc - it would give too many false positives.

Conversion of a pointer to int behaves as you describe, but cannot be
done implicitly. A cast is required to avoid a constraint violation.

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