how to let gcc warn me when I use = in conditions

[Anonymous 7843]

Sometimes, I write = instead of == in if conditions by mistakes. Is
there any way the gcc compiler can give me a warning?

trn's article tree for this thread, so far:

(1)+-(1)--(1)--(1)
|-(1)+-(1)--(1)--(1)--(1)
| |-(1)+-(1)--(1)+-(1)--(1)
| | | \-(1)
| | \-(1)
| \-(1)+-(1)--(1)
| \-(1)+-(1)
| \-(1)
|-(1)--(1)+-(1)+-(1)--(1)
| | \-(1)+-(1)
| | \-(1)+-(1)
| | |-(1)
| | \-(1)--(1)
| \-(1)
|-(1)+-(1)
| \-(1)
|-(1)
\-(1)

And not one of them mentioned "gcc -Wparentheses"
which is the most specific correct answer.

One guy mentioned "gcc -Wall" at least.

 

[Mark]

trn's article tree for this thread, so far:

And not one of them mentioned "gcc -Wparentheses"
which is the most specific correct answer.

May want to read all of the posts... particularly the early ones
posted on the same day as the OP's original question.
Had you done so, you would have seen Greg's response (on 6/23):

 

[websnarf]

What advantage does this have over the more readable

if ((a = b) != 0) ...

First of all, its not more readable, and secondly, if you've been
following along (or just had functioning neurons between your ears)
you'd know that there is no difference. Which is kind of the point. I
actually put the constant first in this case, just to be more
consistent with where I place the constant in other instances. (But
you can see there is an obvious safety advantage if the != is replaced
by a ==, which of course happens easily with conditionals)

 

[Anonymous 7843]

May want to read all of the posts... particularly the early ones
posted on the same day as the OP's original question.
Had you done so, you would have seen Greg's response (on 6/23):

I killfile all crossposts...that's why I didn't see his message.
I should have double checked before making the pronouncement.
Sorry.

 

[Mark]

First of all, its not more readable,

if a equals b is not equal to zero ...
if zero is not equal to a equals b ...
First form IS more readable

and secondly, if you've been
following along (or just had functioning neurons between your ears)
you'd know that there is no difference. Which is kind of the point. I
actually put the constant first in this case, just to be more
consistent with where I place the constant in other instances. (But
you can see there is an obvious safety advantage if the != is replaced
by a ==, which of course happens easily with conditionals)

I must be missing the obvious... to what safety advantage are you referring?
You seem to be insinuating that the following code will generate an error:
if(0 == (a = b)) ...

 

[Michael Mair]

if a equals b is not equal to zero ...
if zero is not equal to a equals b ...
First form IS more readable




I must be missing the obvious... to what safety advantage are you referring?
You seem to be insinuating that the following code will generate an error:
if(0 == (a = b)) ...

Nope. He insinuates that
if ( (a = b) = 0 ) ....
compiles. Which is not correct.
Which in turn renders his statement about the space between Lawrence's
ears crap.
And no, I am not in for the merry Paul-Hsieh-bashing round here.

Cheers
Michael

 

[Mark]

Nope. He insinuates that
if ( (a = b) = 0 ) ....

re-read the last line of his post:
<q> obvious safety advantage if the != is replaced by a == </q>

 

[CBFalconer]

websnarf wrote:
.... snip ...

What advantage does this have over the more readable

if ((a = b) != 0) ...

s/more/less/ (IMO). Of course I would usually prefer:

if (a = b) ....
or
if ((a = b)) ....

which is more readable if you don't tend to confuse == and =.

 

[Michael Mair]

re-read the last line of his post:
<q> obvious safety advantage if the != is replaced by a == </q>

Yep. We are still in a discussion about inadvertently writing "="
instead of "==" as condition.
In this case, there is no advantage of putting the constant first.

Michael

 

[Lawrence Kirby]

First of all, its not more readable,

Not for you perhaps, but for some people certainly. Overall that makes it
less readable.

and secondly, if you've been
following along (or just had functioning neurons between your ears)
you'd know that there is no difference.

Hence my question. If there was a difference in functionality between the
2 forms the question would be moot.

Which is kind of the point. I
actually put the constant first in this case, just to be more
consistent with where I place the constant in other instances. (But
you can see there is an obvious safety advantage if the != is replaced
by a ==, which of course happens easily with conditionals)

But if you had been following this thread you would know that this
perceived safety advantage doesn't really exist. The trick in question is
not general, using it can give you a false sense of security. Most
compilers and failing that checking tools such as lints can check for
this much more reliably, WITHOUT the need to formulate the code in a
less natural way.

Lawrence

 

[Michael Wojcik]

What advantage does this have over the more readable

if ((a = b) != 0) ...

I don't find this version any "more readable" than Paul's. Do any of
the "readability" proponents have any actual evidence to cite in
support of their argument, or is this merely another case of warring
assumptions?

 

[Alan Balmer]

I don't find this version any "more readable" than Paul's. Do any of
the "readability" proponents have any actual evidence to cite in
support of their argument, or is this merely another case of warring
assumptions?

In spite of some attempts to quantify it, readability remains a
subjective measure. Therefore, the second version is more readable for
me simply because I tell you it is. As it happens, a lot of people
agree with me.

 

[Stan R.]

In spite of some attempts to quantify it, readability remains a
subjective measure. Therefore, the second version is more readable for
me simply because I tell you it is. As it happens, a lot of people
agree with me.

While I agree it may be more readable, it think ultimately it depends
*how* you read it.

The first version (to me) read as:
if 0 is not the result of (a = b).

While the latter read as:
if the result of (a = b) is not 0.

I think it's just how you read it?

 

[Mark McIntyre]

In spite of some attempts to quantify it, readability remains a
subjective measure.

Absolutely, though there are some useful metrics,
suchasleavinspacesbetweenletters nOt ranDomLy capitALisIng, and
avoiding with uttermost dexterity the overabundant usage in extremis
of longwinded wittersome and pointlessly extrapolatingly elongeated
word construction paradigms.

Therefore, the second version is more readable for
me simply because I tell you it is.

Horsefeathers.

As it happens, a lot of people
agree with me.

And they're all called Napoleon. Or so the little green men told them.

 

[Mark McIntyre]

While I agree it may be more readable, it think ultimately it depends
*how* you read it.

The first version (to me) read as:
if 0 is not the result of (a = b).

While the latter read as:
if the result of (a = b) is not 0.

I think it's just how you read it?

I read them both the same. Which is not entirely unsurprising, since
they *are* both the same.

 

[websnarf]

Not for you perhaps, but for some people certainly. Overall that makes it
less readable.

Those two sentences are contradictory.

[...] The trick in question is not general, using it can give you a false
sense of security.

Its generality is not relevant. Its primary use is in catching a lot
of low hanging fruit, which is all you can expect a "saftey convention"
to do anyways. The claim about "false sense of security" is not
credible, and just an assertion that you have no way in hell of backing
up.

If one is using practices such as constant-first comparisons,
commenting switch drop-throughs, testing with maximum compiler warnings
on multiple compilers, running your code through lint and using
semantically reflecting naming conventions then one is more likely to
be alert to safety problems, not assuming a sense of safety that isn't
there.

By *itself* it is an insufficient measure for maximal safety, but using
it does not imply that you not using other mechanisms. That would be
Richard Bos-logic.

[...] Most compilers and failing that checking tools such as lints can
check for this much more reliably, WITHOUT the need to formulate the
code in a less natural way.

If you are compiling to one compiler that specifically covers this,
then that might work for you. But I, personally, have not encountered
one single compiler anywhere that satisfactorily issues all the
warnings I would like it to. So even in the best of circumstances I am
basically giving up some warnings anyways, and == vs = testing in
control code is one of those warnings.

 

[Lawrence Kirby]

Those two sentences are contradictory.

Only if you don't expect anybody else to read your code. When there is a
"population" of readers, readability becomes more of a statistical concept.
The fact is that some people find the 0 != form less readable than the !=
0 form. It is certainly possible that for some people the reverse is true,
but I have seen far less evidence of that.

[...] The trick in question is not general, using it can give you a false
sense of security.

Its generality is not relevant. Its primary use is in catching a lot
of low hanging fruit, which is all you can expect a "saftey convention"
to do anyways. The claim about "false sense of security" is not
credible, and just an assertion that you have no way in hell of backing
up.

Not easily, however using a mathod to catch this sort of problem can lead
to a sense of security and where it fails to do so that sense is false.

If one is using practices such as constant-first comparisons,
commenting switch drop-throughs, testing with maximum compiler warnings
on multiple compilers, running your code through lint and using
semantically reflecting naming conventions then one is more likely to
be alert to safety problems, not assuming a sense of safety that isn't
there.

But if you are using compiler warnings then tricks like constant-first
comparisons are pointless since problem cases will be caught anyway, and
much more reliably.

By *itself* it is an insufficient measure for maximal safety, but using
it does not imply that you not using other mechanisms. That would be
Richard Bos-logic.

They are only of any value at all when you are not using other mechanisms.
They don't catch anything that the other mechanisms won't. So the only
time worth considering these tricks is when for whatever reason the other
mechanisms aren't available. 20 years ago these tricks may have had a
legitimate place but times and compilers have moved on.

[...] Most compilers and failing that checking tools such as lints can
check for this much more reliably, WITHOUT the need to formulate the
code in a less natural way.

If you are compiling to one compiler that specifically covers this,
then that might work for you. But I, personally, have not encountered
one single compiler anywhere that satisfactorily issues all the
warnings I would like it to. So even in the best of circumstances I am
basically giving up some warnings anyways, and == vs = testing in
control code is one of those warnings.

If you are honestly saying that the compilers you commonly use don't
support this check and you can't use a lint tool that does then I'm
surprised and will happily concede.

Lawrence

 

[Richard Bos]

Horsefeathers.

So, you would tell Alan that the second version is not, as he says, more
readable to him, because _you_ know better what is readable to _him_
than he himself? What are you, an ergonomist?

And they're all called Napoleon. Or so the little green men told them.

At least one of them is called Richard Bos.

Richard

 

[Alan Balmer]

Absolutely, though there are some useful metrics,
suchasleavinspacesbetweenletters nOt ranDomLy capitALisIng, and
avoiding with uttermost dexterity the overabundant usage in extremis
of longwinded wittersome and pointlessly extrapolatingly elongeated
word construction paradigms.


Horsefeathers.

Hmm... That's amazing. How is it that you know what's more readable to
me, and I, apparently, don't? Do you have any other such insights? I
like chocolate - do you disagree? Am I deluding myself?

 

[Mark McIntyre]

Horsefeathers.

So, you would tell Alan that the second version is not, as he says, more
readable to him, because _you_ know better what is readable to _him_
than he himself? [/QUOTE]

Joking aside, its frequently the case that the designer has a better
idea of what the user wants than the user does. How often have the
users told you they actually like how your old software did stuff,
when you know perfectly well that there's a better way and once they
get used to it, they'll be happier.

What are you, an ergonomist?

Did you just call my pint a jessie?

At least one of them is called Richard Bos.

I'm unclear whether you agree with Alan that he knows what he likes,
or that you also like odd ways of writing stuff, or that you're called
napoleon.