Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Sat, 10 Feb 2024 13:06:13 +0000, Ben Bacarisse wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> I had a look at the MISRA specs, and they say “assignment operators
>>> shall not be used in expressions that yield a boolean value”.
>>
>> Oddly worded. They can't mean what they say.
>
> It is cleverly worded. The idea is obviously to allow chained assignments,
> while disallowing doing a test on the value being assigned. The examples
> make this clear.

See my (corrected) reply to David Brown for why their examples make it
clear that they don't mean what they say.

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> David Brown <david.brown@hesbynett.no> writes:
>
>> On 10/02/2024 14:06, Ben Bacarisse wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>> On Fri, 09 Feb 2024 09:09:41 -0800, Keith Thompson wrote:
>>>>
>>>>> But it's far too late to fix that in any language called "C".
>>>>
>>>> I had a look at the MISRA specs, and they say “assignment operators shall
>>>> not be used in expressions that yield a boolean value”.
>>> Oddly worded. They can't mean what they say.
>>
>> It says "Assignment operators shall not be used in expressions which return
>> Boolean values", at least in my copy of MISRA 1998. Of course, the use of
>> "return" just makes it worse.
>>
>> They explain with examples:
>>
>> """
>> For example write:
>>
>> x = y;
>> if ( x != 0 )
>> {
>> foo();
>> }
>>
>> and not:
>>
>> if ( ( x = y ) != 0 )
>
> x = y is an expression that yields a value of the type of x (after
> lvalue conversion). This is unlikely to be _Bool which (even if they
> mean _Bool instead of Boolean) is why I say they can't mean what they
> say.

I need to correct this because (though I am guessing) they probably mean
that the value of the assignment can't be used in the integer-valued
expression whose operator is !=.

> Your later post in reply to someone else explains that they don't mean
> what they say though, even a few minutes after reading it, I can't
> remember what the clarification was.
>
>> {
>> foo();
>> }
>>
>> or even worse:
>>
>> if ( x = y )
>> {
>> foo();
>> }
>>
>> This helps to avoid getting ‘=’and ‘==’confused, and assists the static
>> detection of mistakes.
>> """
>
> These sorts of guides often use silly examples like this. What is the
> MIRSA preferred why to write
>
> while ((x = get_the_next_x(...)) != NO_MORE_Xs) {
> ... use x ...
> }
>
> ? Presumably they want people to duplicate the call:
>
> x = get_the_next_x(...);
> while (x != NO_MORE_Xs) {
> ... use x ...
> x - get_the_next_y(...);
> }
>
> or maybe use break:
>
> while (1) {
> x = get_the_next_x(...);
> if (x != NO_MORE_Xs) break;
> ... use x ...
> }
>
> Neither looks good to me.

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Fri, 09 Feb 2024 09:09:41 -0800, Keith Thompson wrote:
>>> But it's far too late to fix that in any language called "C".
>>
>> I had a look at the MISRA specs, and they say “assignment operators shall
>> not be used in expressions that yield a boolean value”.
>
> Oddly worded. They can't mean what they say.

I'm fairly sure that what they intended to say was that any expression
used as a condition shall not include an assignment operator. It reads
like they couldn't think of the word "condition" and worked around it by
redefining "boolean" (and never telling anyone what it really means).

And apparently a later edition strengthened and simplified the rule to
ban any use of the result of an assignment.

--
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 10/02/2024 22:45, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 10/02/2024 14:06, Ben Bacarisse wrote:

>> This helps to avoid getting ‘=’and ‘==’confused, and assists the static
>> detection of mistakes.
>> """
>
> These sorts of guides often use silly examples like this. What is the
> MIRSA preferred why to write
>
> while ((x = get_the_next_x(...)) != NO_MORE_Xs) {
> ... use x ...
> }
>
> ? Presumably they want people to duplicate the call:
>
> x = get_the_next_x(...);
> while (x != NO_MORE_Xs) {
> ... use x ...
> x - get_the_next_y(...);
> }
>
> or maybe use break:
>
> while (1) {
> x = get_the_next_x(...);
> if (x != NO_MORE_Xs) break;
> ... use x ...
> }
>
> Neither looks good to me.

Another way is the use the gnu extension to put two statements inside
the condition, although when I tried it now it didn't like it:

while ({x = get_the_next_x(...); x != NO_MORE_Xs;}) {...}

I doubt that would cut any ice with MISRA. You're not technically using
the result of an assignment in an expression, but you're instead putting
entire statements in there!

On Sat, 10 Feb 2024 22:45:01 +0000, Ben Bacarisse wrote:

> or maybe use break:
>
> while (1) {
> x = get_the_next_x(...);
> if (x != NO_MORE_Xs) break;
> ... use x ...
> }

This is the best approach, though in C I generally use “for (;;)” to
indicate “loop forever”. The nice thing is it gracefully generalizes to
more code before (and after) the break, and multiple exits from the loop.

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.

But this point is moot, since the later revision disallows assignment
chaining completely, anyway.

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? If so you could have written

a = b = 1;

and made the same claim.

> But this point is moot, since the later revision disallows assignment
> chaining completely, anyway.

--
Ben.

On Sun, 11 Feb 2024 01:08:51 +0000, 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.

That is the only kind of “boolean” C has.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sun, 11 Feb 2024 01:08:51 +0000, 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.
>
> 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.

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

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

--
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 Sat, 10 Feb 2024 18:00:57 -0800, 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.
>>>
>>
>> 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.

No, it is not:

>>> But the equality and relational operators still yield results of type
>>> int with value 0 or 1.

See, no “distinct boolean type”.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sat, 10 Feb 2024 18:00:57 -0800, 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.
>>>>
>>>
>>> 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.
>
> No, it is not:

Incorrect.

>>>> But the equality and relational operators still yield results of type
>>>> int with value 0 or 1.

Yes, and?

> See, no “distinct boolean type”.

I see. You're simply wrong.

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

Again, C has a distinct boolean type *that it doesn't use in some
contexts where it would make sense to do so, for historical reasons*.

Which part of that do you disagree with?

--
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 10/02/2024 13:03, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On 09/02/2024 22:41, Ben Bacarisse wrote:
> ...
>>> Yes, it's a good summary of what passes for "common knowledge". But I
>>> was talking about something else altogether -- actual bugs found in real
>>> code, maybe taken from an analysis of security advisories. How many can
>>> (to take one example) be attributed, in whole or in part, for using
>>> assignment in a larger expression?
>>>
>> I did have an example recently in my own code recently (shipped,
>> commercial, tested, supposedly bug free code). There was an assignment in a
>> if expression which somehow slipped through. But it's only one
>> example.
>
> Can you post a link to the post? I know you've switch readers, so it
> may not be obvious how to do that, but I'd appreciate it.
>
Now is my memory playing tricks on me?

I hae a distinct memory of taking out that bug recently. But all the
changes are kept in git repositories. I've checked the repositories, and
that bug is nowhere to be seen.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

bart wrote:
> On 09/02/2024 17:22, Malcolm McLean wrote:
>> On 09/02/2024 17:09, Keith Thompson wrote:
>>>
>>> (It's possible I'm overgeneralizing. For example, a programmer who
>>> commonly switches between C and other languages might still mix up "="
>>> and "==" occasionally.)
>>>
>>
>> I had do to my PhD in Fortran, for my sins. It's := for assignment and
>> = for comparison, and when I switched back to C, I was always writing
>> "=" for "==".
>
> Fortran must have changed considerably since I last used it.
>
> It was "=" to assign, and ".EQ." for equality.
>
> I assume you mean another language. My normal one does use := and = like
> that, and switching to/from C gives problems: you write = in C instead
> of ==, and in mine I'd write = instead of :=. However:
>
> a = b
>
> was a no-op in my language (or rather, it compared then discarded the
> result), leading to puzzling bugs. Now I usually detect such statements.

it seem clear by me that if someone want upbild c-liek language
(and many people want including me) unicode is needed...
as i previously said yopu need one sign for == and one sign for = (or :=)

this conclusion comes from my study of what is needed and what
could be replaced...this basic set of operators/signs in ansi is to
natrrow and yet those wighs come from outside computer world

imo such operation as assigment is kinda computer specific and = dont
wuite fits

watching the unicode signs and tryin slightly (initially, spending few
minutes on it as for now)

https://en.wikipedia.org/wiki/List_of_Unicode_characters

i didnt find what would fit and what fits best

temporarely i put empty square as example

x▭100, y▭200, z▭x+y

definitelly assuming that i need to drop ansi and find in unicode is
some kind of decision (step up)

fir wrote:
> bart wrote:
>> On 09/02/2024 17:22, Malcolm McLean wrote:
>>> On 09/02/2024 17:09, Keith Thompson wrote:
>>>>
>>>> (It's possible I'm overgeneralizing. For example, a programmer who
>>>> commonly switches between C and other languages might still mix up "="
>>>> and "==" occasionally.)
>>>>
>>>
>>> I had do to my PhD in Fortran, for my sins. It's := for assignment and
>>> = for comparison, and when I switched back to C, I was always writing
>>> "=" for "==".
>>
>> Fortran must have changed considerably since I last used it.
>>
>> It was "=" to assign, and ".EQ." for equality.
>>
>> I assume you mean another language. My normal one does use := and = like
>> that, and switching to/from C gives problems: you write = in C instead
>> of ==, and in mine I'd write = instead of :=. However:
>>
>> a = b
>>
>> was a no-op in my language (or rather, it compared then discarded the
>> result), leading to puzzling bugs. Now I usually detect such statements.
>
> it seem clear by me that if someone want upbild c-liek language
> (and many people want including me) unicode is needed...
> as i previously said yopu need one sign for == and one sign for = (or :=)
>
> this conclusion comes from my study of what is needed and what
> could be replaced...this basic set of operators/signs in ansi is to
> natrrow and yet those wighs come from outside computer world
>
> imo such operation as assigment is kinda computer specific and = dont
> wuite fits
>
> watching the unicode signs and tryin slightly (initially, spending few
> minutes on it as for now)
>
> https://en.wikipedia.org/wiki/List_of_Unicode_characters
>
> i didnt find what would fit and what fits best
>
> temporarely i put empty square as example
>
> x▭100, y▭200, z▭x+y
>
> definitelly assuming that i need to drop ansi and find in unicode is
> some kind of decision (step up)
>
>
>
>
>
in fact i also think that more then one sign for asigments is needed

for example this x = foo(y) is something other than this x = y
and it is specially seen when using things liek

x y = foo(a,b,c)
becouse if i want to drep thsi gothic decorators as i name them you got

x y foo a b c

and you could want to denote optionally what is variables ina and
what is variables out and if so the = would look like

x= y= foo <-a <-b <-c thus output of the function probably should be
noted by differnt sign then assigment as it would increase readibility

x' y' foo "a "b "c

i dont knov hovever what signs it should be and there should be find a
way what can be optional

fir wrote:
> fir wrote:
>> bart wrote:
>>> On 09/02/2024 17:22, Malcolm McLean wrote:
>>>> On 09/02/2024 17:09, Keith Thompson wrote:
>>>>>
>>>>> (It's possible I'm overgeneralizing. For example, a programmer who
>>>>> commonly switches between C and other languages might still mix up "="
>>>>> and "==" occasionally.)
>>>>>
>>>>
>>>> I had do to my PhD in Fortran, for my sins. It's := for assignment and
>>>> = for comparison, and when I switched back to C, I was always writing
>>>> "=" for "==".
>>>
>>> Fortran must have changed considerably since I last used it.
>>>
>>> It was "=" to assign, and ".EQ." for equality.
>>>
>>> I assume you mean another language. My normal one does use := and = like
>>> that, and switching to/from C gives problems: you write = in C instead
>>> of ==, and in mine I'd write = instead of :=. However:
>>>
>>> a = b
>>>
>>> was a no-op in my language (or rather, it compared then discarded the
>>> result), leading to puzzling bugs. Now I usually detect such statements.
>>
>> it seem clear by me that if someone want upbild c-liek language
>> (and many people want including me) unicode is needed...
>> as i previously said yopu need one sign for == and one sign for = (or :=)
>>
>> this conclusion comes from my study of what is needed and what
>> could be replaced...this basic set of operators/signs in ansi is to
>> natrrow and yet those wighs come from outside computer world
>>
>> imo such operation as assigment is kinda computer specific and = dont
>> wuite fits
>>
>> watching the unicode signs and tryin slightly (initially, spending few
>> minutes on it as for now)
>>
>> https://en.wikipedia.org/wiki/List_of_Unicode_characters
>>
>> i didnt find what would fit and what fits best
>>
>> temporarely i put empty square as example
>>
>> x▭100, y▭200, z▭x+y
>>
>> definitelly assuming that i need to drop ansi and find in unicode is
>> some kind of decision (step up)
>>
>>
>>
>>
>>
> in fact i also think that more then one sign for asigments is needed
>
> for example this x = foo(y) is something other than this x = y
> and it is specially seen when using things liek
>
> x y = foo(a,b,c)
> becouse if i want to drep thsi gothic decorators as i name them you got
>
> x y foo a b c
>
> and you could want to denote optionally what is variables ina and
> what is variables out and if so the = would look like
>
> x= y= foo <-a <-b <-c thus output of the function probably should be
> noted by differnt sign then assigment as it would increase readibility
>
> x' y' foo "a "b "c
>
> i dont knov hovever what signs it should be and there should be find a
> way what can be optional
>
>
the decision just to open up unicode can simplify things

for exampel i was wondering back than herdly if

a b c = d e f

should be a 3 element 'vector' or 5 element vector..decision to take
unicode just allow to take one = for 1-element scalar assigment
and soem other sign resembling = for n-element vector assigment
...without it there is some more hard way i probably will even not explore

(and i probably resolved the trouble of what to do with comma "'"

a b, c d e, f

comam should be separator something liek ";" today
those "tuples" separated by space should be vectors, or
particles/particules as i neme them

im presently not sure if some suitable 2-element particules not reserve
for assigments liek

x 1, y 2

means x=1, y=2 but x 1 2 or foo x 1 are 3-element vectors, but im not
sure if this will not break something as it "przeslania" (forget an
englis word, covers?) the 2-element vector syntax i maybe would need

hovever this pure vectors laying in white emptiness of context
of much nothing maybe are worth to cover by something more usable

as some could say this context is wasted

fir wrote:
> fir wrote:
>> bart wrote:
>>> On 09/02/2024 17:22, Malcolm McLean wrote:
>>>> On 09/02/2024 17:09, Keith Thompson wrote:
>>>>>
>>>>> (It's possible I'm overgeneralizing. For example, a programmer who
>>>>> commonly switches between C and other languages might still mix up "="
>>>>> and "==" occasionally.)
>>>>>
>>>>
>>>> I had do to my PhD in Fortran, for my sins. It's := for assignment and
>>>> = for comparison, and when I switched back to C, I was always writing
>>>> "=" for "==".
>>>
>>> Fortran must have changed considerably since I last used it.
>>>
>>> It was "=" to assign, and ".EQ." for equality.
>>>
>>> I assume you mean another language. My normal one does use := and = like
>>> that, and switching to/from C gives problems: you write = in C instead
>>> of ==, and in mine I'd write = instead of :=. However:
>>>
>>> a = b
>>>
>>> was a no-op in my language (or rather, it compared then discarded the
>>> result), leading to puzzling bugs. Now I usually detect such statements.
>>
>> it seem clear by me that if someone want upbild c-liek language
>> (and many people want including me) unicode is needed...
>> as i previously said yopu need one sign for == and one sign for = (or :=)
>>
>> this conclusion comes from my study of what is needed and what
>> could be replaced...this basic set of operators/signs in ansi is to
>> natrrow and yet those wighs come from outside computer world
>>
>> imo such operation as assigment is kinda computer specific and = dont
>> wuite fits
>>
>> watching the unicode signs and tryin slightly (initially, spending few
>> minutes on it as for now)
>>
>> https://en.wikipedia.org/wiki/List_of_Unicode_characters
>>
>> i didnt find what would fit and what fits best
>>
>> temporarely i put empty square as example
>>
>> x▭100, y▭200, z▭x+y
>>
>> definitelly assuming that i need to drop ansi and find in unicode is
>> some kind of decision (step up)
>>
>>
>>
>>
>>
> in fact i also think that more then one sign for asigments is needed
>
> for example this x = foo(y) is something other than this x = y
> and it is specially seen when using things liek
>
> x y = foo(a,b,c)
> becouse if i want to drep thsi gothic decorators as i name them you got
>
> x y foo a b c
>
> and you could want to denote optionally what is variables ina and
> what is variables out and if so the = would look like
>
> x= y= foo <-a <-b <-c thus output of the function probably should be
> noted by differnt sign then assigment as it would increase readibility
>
> x' y' foo "a "b "c
>
> i dont knov hovever what signs it should be and there should be find a
> way what can be optional
>
>

x y foo a b c

optional is not bed also clever editir sein such particles could
set output variables as one color input as another and bold teh function
call name

On 10/02/2024 22:49, Lawrence D'Oliveiro wrote:
> On Sat, 10 Feb 2024 16:53:39 +0100, David Brown wrote:
>
>> In MISRA C 2012, the assignment rule is simpler : "The result of an
>> assignment operator should not be used".
>
> Interesting. So no more chained assignments?
>

Correct.

Chained assignments are used in three ways, I would say :

1. Inappropriately grouping things that are logically separate :

index = sum = 0;

Splitting these makes code clearer.

2. Grouping things to save lines using old-style "declare variables at
the top of the function" code:

int a, b;
...
a = b = 0;

Rather write:

int a = 0;
int b = 0;

3. Cases where grouping really does make sense :

x = y = z = initial_value;

I don't see a problem with case 3, but these are so rare that it is not
a problem if a coding style disallows them.

On 10/02/2024 23:45, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 10/02/2024 14:06, Ben Bacarisse wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>> On Fri, 09 Feb 2024 09:09:41 -0800, Keith Thompson wrote:
>>>>
>>>>> But it's far too late to fix that in any language called "C".
>>>>
>>>> I had a look at the MISRA specs, and they say “assignment operators shall
>>>> not be used in expressions that yield a boolean value”.
>>> Oddly worded. They can't mean what they say.
>>
>> It says "Assignment operators shall not be used in expressions which return
>> Boolean values", at least in my copy of MISRA 1998. Of course, the use of
>> "return" just makes it worse.
>>
>> They explain with examples:
>>
>> """
>> For example write:
>>
>> x = y;
>> if ( x != 0 )
>> {
>> foo();
>> }
>>
>> and not:
>>
>> if ( ( x = y ) != 0 )
>
> x = y is an expression that yields a value of the type of x (after
> lvalue conversion). This is unlikely to be _Bool which (even if they
> mean _Bool instead of Boolean) is why I say they can't mean what they
> say.
>

To be clear - I am quoting MISRA here, not saying I think it is
necessarily a good idea, or that the MISRA standards explain it well.

(They don't mean "_Bool" here, because that was MISRA 1998, which
considered only C90.)

> Your later post in reply to someone else explains that they don't mean
> what they say though, even a few minutes after reading it, I can't
> remember what the clarification was.
>
>> {
>> foo();
>> }
>>
>> or even worse:
>>
>> if ( x = y )
>> {
>> foo();
>> }
>>
>> This helps to avoid getting ‘=’and ‘==’confused, and assists the static
>> detection of mistakes.
>> """
>
> These sorts of guides often use silly examples like this.

Agreed.

> What is the
> MIRSA preferred why to write
>
> while ((x = get_the_next_x(...)) != NO_MORE_Xs) {
> ... use x ...
> }
>
> ? Presumably they want people to duplicate the call:
>
> x = get_the_next_x(...);
> while (x != NO_MORE_Xs) {
> ... use x ...
> x - get_the_next_y(...);
> }
>
> or maybe use break:
>
> while (1) {
> x = get_the_next_x(...);
> if (x != NO_MORE_Xs) break;
> ... use x ...
> }
>
> Neither looks good to me.
>

That's the issue with almost any rule - there are almost always cases
where breaking the rule leads to clearer code (possibly clearer simply
because it is idiomatic, and therefore familiar).

On 11/02/2024 01:11, bart wrote:
> On 10/02/2024 22:45, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 10/02/2024 14:06, Ben Bacarisse wrote:
>
>>> This helps to avoid getting ‘=’and ‘==’confused, and assists the static
>>> detection of mistakes.
>>> """
>>
>> These sorts of guides often use silly examples like this.  What is the
>> MIRSA preferred why to write
>>
>>    while ((x = get_the_next_x(...)) != NO_MORE_Xs) {
>>        ... use x ...
>>    }
>>
>> ?  Presumably they want people to duplicate the call:
>>
>>    x = get_the_next_x(...);
>>    while (x != NO_MORE_Xs) {
>>       ... use x ...
>>       x - get_the_next_y(...);
>>    }
>>
>> or maybe use break:
>>
>>    while (1) {
>>       x = get_the_next_x(...);
>>       if (x != NO_MORE_Xs) break;
>>       ... use x ...
>>    }
>>
>> Neither looks good to me.
>
> Another way is the use the gnu extension to put two statements inside
> the condition, although when I tried it now it didn't like it:
>
>     while ({x = get_the_next_x(...); x != NO_MORE_Xs;}) {...}
>
> I doubt that would cut any ice with MISRA. You're not technically using
> the result of an assignment in an expression, but you're instead putting
> entire statements in there!

MISRA disallows extensions, despite most compilers used by people
writing MISRA code /requiring/ extensions to do the job.

MISRA 1998 starts with these rules :

1. All code shall conform to ISO 9899 standard C, with no extensions
permitted.

2. Code written in languages other than C should only be used if
there is a defined interface standard for object code to which the
compilers/assemblers for both languages conform.

3. Assembly language functions that are called from C should be
written as C functions containing only in-line assembly language,
and in-line assembly language should not be embedded in normal
C code.

So you are only allowed to use C for your code, conforming to standard
C90, without extensions. But you are allowed to use code in other
languages. And you can't use extensions for your compiler, but if you
use assembly functions, they must be in C inline assembly - which
necessitates extensions.

Did I mention that I thought MISRA was a bit mixed up?

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

On 10/02/2024 22:48, Lawrence D'Oliveiro wrote:
> On Sat, 10 Feb 2024 13:06:13 +0000, Ben Bacarisse wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> I had a look at the MISRA specs, and they say “assignment operators
>>> shall not be used in expressions that yield a boolean value”.
>>
>> Oddly worded. They can't mean what they say.
>
> It is cleverly worded. The idea is obviously to allow chained assignments,
> while disallowing doing a test on the value being assigned. The examples
> make this clear.

No. It was badly worded. They had been trying to rule out "if (x = y)"
and requiring it to be written "x = y; if (x != 0) ...".

They did not intend to allow chained assignments - they simply didn't
think to rule them out in MISRA 1998. In MISRA 2012, they changed that
to explicitly rule out /any/ use of the value of an assignment expression.

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

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

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

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.

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