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.
>
> as some maybe know im from time to time write my compiler on c based
> langage and also i hardly think how to simplify and expand syntax and
> construction
>
> as to this problem how ewentually replace = and == at present time i
> just found this problem unresolvable :c
>
>
> what i think = coud eventually stay though it also could have
> alternative.. == is in turn clearly wrong but one would need unicode
> sign for this i guess.. there is need for some sign like = with a small
> "?" above it
>
> ≟ possibly
>
> a≟b
>
in fact i could conclude:

a=b assigment should be something that resembles "=" but in the
direction of <- or something like that
a==b comparsion should be something that resembles "=" but in the
direction of something like comparsion sign

bioth obviously should be one sign..in asci there is no way to resolve
that i guess

i guess even = could be for comparsion but yopu would need another =
more in direction like <- (but not quite) for assigments

in asci that cont be done properly (i think)
in asci you only can have some aproximation of this, and i probably
would hold a=b for assigment and use a?=b for comparison (but only as
approximation and use unicode for full 'version')

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> If C had used ":=" for assignment and "=" for comparison (and "=="
> probably not used for anything), the problem would never have come up,
> because ":=" doesn't look like a comparison even to a newbie. But it's
> far too late to fix that in any language called "C".

If I were designing a new language, I'd consider using ":=" for
assignment, "==" for equality, and not using "=" for anything.

In (nearly?) all languages I'm aware of, ":=" either doesn't exist or
means assignment, and "==" either doesn't exist or means equality. I'd
avoid "=" because it's ambiguous across languages (and that's almost
entirely C's fault, inherited from B).

Historically, C's predecessor B used "=" for assignment and "==" for
equality, while B's predecessor BCPL used ":=" for assignment and "="
for equality.

--
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 Fri, 9 Feb 2024 19:47:45 -0000 (UTC), Blue-Maned_Hawk wrote:

> There are too many situations where assignment being an expression is a
> useful facet of the language; i am not willing to sacrifice that for an
> ill-defined ideal of “safety”.

If you consider it “ill-defined”, consider the number of people who have
developed the habit of writing

if (NULL == p) ...

instead of the more natural

if (p == NULL) ...

Keith Thompson wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> [...]
>> If C had used ":=" for assignment and "=" for comparison (and "=="
>> probably not used for anything), the problem would never have come up,
>> because ":=" doesn't look like a comparison even to a newbie. But it's
>> far too late to fix that in any language called "C".
>
> If I were designing a new language, I'd consider using ":=" for
> assignment, "==" for equality, and not using "=" for anything.
>
> In (nearly?) all languages I'm aware of, ":=" either doesn't exist or
> means assignment, and "==" either doesn't exist or means equality. I'd
> avoid "=" because it's ambiguous across languages (and that's almost
> entirely C's fault, inherited from B).
>
> Historically, C's predecessor B used "=" for assignment and "==" for
> equality, while B's predecessor BCPL used ":=" for assignment and "="
> for equality.
>

it io not in the spirit of c (and c design intentions) SO
people like you or the guy who want to consider to remove
assigments in expressions dont understand c
(i understand it at least better, question is if fully)

On 2024-02-09, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> [...]
>> If C had used ":=" for assignment and "=" for comparison (and "=="
>> probably not used for anything), the problem would never have come up,
>> because ":=" doesn't look like a comparison even to a newbie. But it's
>> far too late to fix that in any language called "C".
>
> If I were designing a new language, I'd consider using ":=" for
> assignment, "==" for equality, and not using "=" for anything.
>
> In (nearly?) all languages I'm aware of, ":=" either doesn't exist or
> means assignment, and "==" either doesn't exist or means equality. I'd
> avoid "=" because it's ambiguous across languages (and that's almost
> entirely C's fault, inherited from B).

Some of the credit must go to classic BASIC!

I seem to remember than in classic, line-numbered BASICs on 8 bit
micros, the = token was used both for assignment and comparison!

300 I = I + 1
310 IF I = 10 GOTO 340

If you have a dedicated assignment statement, you can pull this kind
of stunt. Just like C can distinguish initialization from assignment.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Richard Harnden <richard.nospam@gmail.invalid> writes:

> On 09/02/2024 13:17, Ben Bacarisse wrote:
>> Richard Harnden <richard.nospam@gmail.invalid> writes:
>>
>>> On 09/02/2024 10:16, Ben Bacarisse wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>
>>>>> On 09/02/2024 01:39, Lawrence D'Oliveiro wrote:
>>>>>> 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.
>>>>>
>>>>> I think that C would have been a safer language if assignment had been a
>>>>> statement, not an expression
>>>> Surely someone has studied this, no? There must be some paper
>>>> describing bugs "in the wild"* and categorising them by what language
>>>> features would have made them either impossible or less likely. I don't
>>>> know of any (it was not even remotely my field) but there is such a
>>>> large pool of data out there I can't imagine that it's not been done.
>>>> * I mean to exclude bugs that get found early. For example, I've never
>>>> seen a = vs. == bug that survived even the most crude tests (and most,
>>>> like many other typo bugs, don't survive compilation without being
>>>> picked up).
>>>
>>> This is what ChatGPT says ...
>> Seriously? You do know how large language models work, yes?
>>
>
> Sure: It has read the entire internet - especially the the bit about how
> Rust is better than C, apparently - and regurgitates the same.
>
> Considering my five seconds of effort; I didn't think it was /that/ bad of
> a list.

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?

--
Ben.

David Brown <david.brown@hesbynett.no> writes:

> On 09/02/2024 11:16, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 09/02/2024 01:39, Lawrence D'Oliveiro wrote:
>>>> 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.
>>>
>>> I think that C would have been a safer language if assignment had been a
>>> statement, not an expression
>> Surely someone has studied this, no? There must be some paper
>> describing bugs "in the wild"* and categorising them by what language
>> features would have made them either impossible or less likely. I don't
>> know of any (it was not even remotely my field) but there is such a
>> large pool of data out there I can't imagine that it's not been done.
>
> I think it is very difficult to get good statistics on this kind of thing.
> You can't really do a controlled study comparing one group programming in
> "C where assignment is an expression" with a group programming in "C where
> assignment is a statement". And you certainly can't do a double-blind
> placebo controlled test!

True. But there are literally thousands of significant bugs logged
every day in key systems components. A retrospective analysis of these
would, I think, be very interesting.

--
Ben.

On 09/02/2024 22:41, Ben Bacarisse wrote:
> Richard Harnden <richard.nospam@gmail.invalid> writes:
>
>> On 09/02/2024 13:17, Ben Bacarisse wrote:
>>> Richard Harnden <richard.nospam@gmail.invalid> writes:
>>>
>>>> On 09/02/2024 10:16, Ben Bacarisse wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>
>>>>>> On 09/02/2024 01:39, Lawrence D'Oliveiro wrote:
>>>>>>> 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.
>>>>>>
>>>>>> I think that C would have been a safer language if assignment had been a
>>>>>> statement, not an expression
>>>>> Surely someone has studied this, no? There must be some paper
>>>>> describing bugs "in the wild"* and categorising them by what language
>>>>> features would have made them either impossible or less likely. I don't
>>>>> know of any (it was not even remotely my field) but there is such a
>>>>> large pool of data out there I can't imagine that it's not been done.
>>>>> * I mean to exclude bugs that get found early. For example, I've never
>>>>> seen a = vs. == bug that survived even the most crude tests (and most,
>>>>> like many other typo bugs, don't survive compilation without being
>>>>> picked up).
>>>>
>>>> This is what ChatGPT says ...
>>> Seriously? You do know how large language models work, yes?
>>>
>>
>> Sure: It has read the entire internet - especially the the bit about how
>> Rust is better than C, apparently - and regurgitates the same.
>>
>> Considering my five seconds of effort; I didn't think it was /that/ bad of
>> a list.
>
> 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.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

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

On 2024-02-10, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> 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”.

I skimmed through MISRA some years ago and wasn't very impressed by it,
actually.

It's full the kind of coding rules that you might want to enforce
if you have to produce a bunch of C, and the only people you are given
are ones who shouldn't even remotely be doing such a thing.

We might call those coders Les MISRAbles. :)

The rules are not suitable for people who know what they are doing
(and use tools effectively) and detrimental to the code.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

I presume they mean expressions used as conditions, but unless they
define what they the phrase "boolean value" somwhere, that's not what
they wrote.

--
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 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”.
>
> I presume they mean expressions used as conditions, but unless they
> define what they the phrase "boolean value" somwhere, that's not what
> they wrote.

Editing error.

I presume they mean expressions used as conditions, but unless they
define what they *mean by* the phrase "boolean value" somwhere, that's
not what they wrote.

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

> On Fri, 9 Feb 2024 19:47:45 -0000 (UTC), Blue-Maned_Hawk wrote:
>
>> There are too many situations where assignment being an expression is a
>> useful facet of the language; i am not willing to sacrifice that for an
>> ill-defined ideal of “safety”.
>
> If you consider it “ill-defined”, consider the number of people who have
> developed the habit of writing
>
> if (NULL == p) ...
>
> instead of the more natural
>
> if (p == NULL) ...

Y'know, there's some coding style guide that explicitly states _not_ to do
those kinds of “yoda comparisons”, but i've never seen any code that
actually uses them.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
LOCAL MAN'S SPEECH ENTIRELY INCONSEQUENTIAL

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.

--
Ben.

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.

--
Ben.

On 09/02/2024 23:43, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 09/02/2024 11:16, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 09/02/2024 01:39, Lawrence D'Oliveiro wrote:
>>>>> 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.
>>>>
>>>> I think that C would have been a safer language if assignment had been a
>>>> statement, not an expression
>>> Surely someone has studied this, no? There must be some paper
>>> describing bugs "in the wild"* and categorising them by what language
>>> features would have made them either impossible or less likely. I don't
>>> know of any (it was not even remotely my field) but there is such a
>>> large pool of data out there I can't imagine that it's not been done.
>>
>> I think it is very difficult to get good statistics on this kind of thing.
>> You can't really do a controlled study comparing one group programming in
>> "C where assignment is an expression" with a group programming in "C where
>> assignment is a statement". And you certainly can't do a double-blind
>> placebo controlled test!
>
> True. But there are literally thousands of significant bugs logged
> every day in key systems components. A retrospective analysis of these
> would, I think, be very interesting.
>

That would be interesting, yes. It sounds like a good task for a
postgraduate student thesis.

On 10/02/2024 04:06, Kaz Kylheku wrote:
> On 2024-02-10, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> 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”.
>
> I skimmed through MISRA some years ago and wasn't very impressed by it,
> actually.
>
> It's full the kind of coding rules that you might want to enforce
> if you have to produce a bunch of C, and the only people you are given
> are ones who shouldn't even remotely be doing such a thing.
>
> We might call those coders Les MISRAbles. :)
>
> The rules are not suitable for people who know what they are doing
> (and use tools effectively) and detrimental to the code.
>

The MISRA rules are a mixed bag. Some of them are definitely things
that should be considered obvious - such as "don't rely on the results
of undefined behaviour". And some are also more appropriate for people
using poorer tools (or who don't know how to use their tools well).
Some are directly unhelpful - it talks about an "effective type" system
that is, as I recall, subtly wrong.

It is worth remembering the target audience, especially for older
versions of MISRA (their rules have been updated several times). It
used to be the norm that compilers for microcontrollers were a bit odd -
they could be very poor at optimising (leading to people doing dangerous
tricks, or at least unclear code, to get faster results), and poor at
warnings. They often had lots of extensions, and non-conforming
features. (I've seen an 8-bit sort-of-C compiler that intentionally
does not promote 8-bit types to "int" as required - and that was a big
name, big price toolchain.) These tools also change slowly - many did
not have decent C99 support until perhaps fifteen years ago, so you
couldn't use the newer and better C version. And the tools can have
more bugs than more popular toolchains with wider audiences.

A fair proportion of people programming for small embedded systems are
primarily electronics engineers and other hardware people that have
moved into software. They often lack significant formal education in
programming or in C. So guidelines here can match that.

All in all, this means MISRA can be useful and appropriate in some
cases, and inappropriate in other cases - they are certainly not
something you'd use for all C programming.

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

> On Fri, 9 Feb 2024 00:53:42 +0000, Malcolm McLean wrote:
>
>> while( (ch = fgetc(fp)) != EOF)
>>
>> is the idiomatic way of accessing a stream a character by character in
>> C. So you would disallow this.
>
> Yes!

What code would you write to accomplish the same thing, under the
assumption that what you're proposing is adopted?

As long as I'm asking, how would you write it in C as it is now?

On 10/02/2024 05:17, Keith Thompson wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> 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”.
>>
>> I presume they mean expressions used as conditions, but unless they
>> define what they the phrase "boolean value" somwhere, that's not what
>> they wrote.
>
> Editing error.
>
> I presume they mean expressions used as conditions, but unless they
> define what they *mean by* the phrase "boolean value" somwhere, that's
> not what they wrote.
>

In MISRA 1998, the explanation for that rule includes:

"""
Strictly speaking, in C, there is no Boolean type, but there is a
conceptual difference between expressions which return a numeric value
and expressions which return a Boolean value.

If assignments are required then they must be performed separately
outside of any expressions which are effectively of Boolean type.
"""

MISRA regularly uses its own terms that are different from the Standard
C terms, which IMHO is needlessly confusing and inaccurate. Sometimes
these terms are defined, sometimes not. "Boolean" and "Effectively
Boolean value" are not defined anywhere in MISRA 1998.

(And in MISRA 2012 there is the extraordinary, messy, vague and badly
defined idea of "the essential type model" which seems to be what the
MISRA authors wished C had for its types, operators and conversions, but
which is at odds with what C really has.)

In MISRA C 2012, the assignment rule is simpler : "The result of an
assignment operator should not be used".

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 )
{
foo();
}

or even worse:

if ( x = y )
{
foo();
}

This helps to avoid getting ‘=’and ‘==’confused, and assists the static
detection of mistakes.
"""

On 10/02/2024 09:05, Blue-Maned_Hawk wrote:
> Lawrence D'Oliveiro wrote:
>
>> On Fri, 9 Feb 2024 19:47:45 -0000 (UTC), Blue-Maned_Hawk wrote:
>>
>>> There are too many situations where assignment being an expression is a
>>> useful facet of the language; i am not willing to sacrifice that for an
>>> ill-defined ideal of “safety”.
>>
>> If you consider it “ill-defined”, consider the number of people who have
>> developed the habit of writing
>>
>> if (NULL == p) ...
>>
>> instead of the more natural
>>
>> if (p == NULL) ...
>
> Y'know, there's some coding style guide that explicitly states _not_ to do
> those kinds of “yoda comparisons”, but i've never seen any code that
> actually uses them.
>

I have seen them all over the place. They are very common in code
written to MISRA, even though they are not required by the standard. It
is also common in code written by people who have been taught that C is
"dangerous" and you need to write "safe" C like :

if (42 == x) ...

or

if (TRUE == (x < y)) ...

(I'm not making this up.)

On Sat, 10 Feb 2024 15:02:30 +0100, David Brown wrote:

> All in all, this means MISRA can be useful and appropriate in some
> cases, and inappropriate in other cases - they are certainly not
> something you'd use for all C programming.

Nevertheless, they are based on real-world experience with certain all-
too-common errors with C programming, are they not.

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.

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?

Python manages to allow these, without allowing assignments to actually
have a value as such.

Of course, Python has its own pitfalls, such as

a = b = []

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.

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.