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

[PengYu.UT]

Hi,

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

Best wishes,
Peng

 

[Emmanuel Delahaye]

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

-W -Wall. I also recommend -O1 or -O2 for dataflow analysing.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

I once asked an expert COBOL programmer, how to
declare local variables in COBOL, the reply was:
"what is a local variable?"

 

[PengYu.UT]

-W -Wall. I also recommend -O1 or -O2 for dataflow analysing.

What do you mean by "dataflow analysing"? Thanks!

 

[CBFalconer]

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

Simple. Get in the habit of putting the constant first. I.e:

int ch;

....
if (EOF == ch) ....

will complain loudly if you write = in place of ==. Similarly:

while (EOF != (ch = getc(fp))) {
/* do unspeakable things to and with ch */
}

 

[Randy Howard]

Simple. Get in the habit of putting the constant first. I.e:

int ch;

....
if (EOF == ch) ....

Which will only work in the case of a constant inside the if.
If you have two variables inside, it doesn't apply.

You can get gcc to recommend something like "suggest () around
truth value" or something (I don't remember the exact text
offhand) by turning up the warning level, although it will
whine about legal, but perhaps crufty code.

 

[Stan R.]

Hi,

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

What version are you using?

 

[Alfred Z. Newmane]

What version are you using?

From what I've seen, both 2.9x and 3.x behave the same way in this
respect.

 

[Alan Balmer]

Simple. Get in the habit of putting the constant first. I.e:

int ch;

....
if (EOF == ch) ....

will complain loudly if you write = in place of ==. Similarly:

while (EOF != (ch = getc(fp))) {
/* do unspeakable things to and with ch */
}

Now, all I have to do is somehow guarantee that all if statements have
a constant.

 

[Greg]

From what I've seen, both 2.9x and 3.x behave the same way in this
respect.

You can also get in the habit of placing the rvalue (or constant value)
on the left of a comparison expression:

if (0 == myVar)
{
...
}

Now the code won't compile if a = replaces the ==.

Greg

 

[Alf P. Steinbach]

* Greg:

You can also get in the habit of placing the rvalue (or constant value)
on the left of a comparison expression:

if (0 == myVar)
{
...
}

Now the code won't compile if a = replaces the ==.

Although I won't recommend it, and it's formally Undefined Behavior, it's
possible to #define the words 'if' and 'while' so that they require a 'bool'
argument; that will catch many but not all '=='/'=' typos.

From a readability perspective this left-side thing is awkward and unnatural.

From the perspective of catching typos and mishaps, it's prone to the same kind
of errors it's meant to catch... ;-)

The best advice I know is to be very careful when writing code, and to TEST.

Just my 3c.

 

[CBFalconer]

Now, all I have to do is somehow guarantee that all if statements
have a constant.

Well, those that don't can usually legitimately use the '=' in
place of '=='. If we carry this reasoning to the extreme the
compiler should execute:

fprintf(stderr, "WARNING \"%s\" may be invalid\n",
current_token);

after each lexical extraction from the source! I envision
marketing difficulties.

 

[Greg]

From what I've seen, both 2.9x and 3.x behave the same way in this
respect.

You would want to compile with the -Wparentheses command line option.

Greg

 

[=?ISO-8859-1?Q?Bal=E1zs_Szalai?=]

You can also get in the habit of placing the rvalue (or constant value)

From a readability perspective this left-side thing is awkward and unnatural.

I hear this argument quite often, but after giving it a try I got used to it.

It's quite rare that it points out a =/== mistake, but (imo) it could even aid reading:
if (0 = aNotTooShortFunction( argument1, argument2, argument3 ))
if you have a couple of these, there's no "eye-work" to get the point...
.... assuming that the function name indicates it's type of result.
Otherwise the value is placed far from the function name and just floating somewhere on the right.

Similar to this I've heard the "?:" criticised a lot for readibility/understandability problems.
Same for "++". And after all what the heck is "i = 1;" isn't it 'i equals 1'? ;-]

 

[Richard Bos]

Simple. Get in the habit of putting the constant first.

....and be tricked by your own cleverness the next time you want to
compare two variables, because you've got disused to pay attention to
what you write.

if (EOF == ch) ....

Also, this is semantically the wrong message. You don't want to inspect
EOF, and see if its current value is that of ch; you want to know
whether the current character is End-Of-File.

Richard

 

[Lawrence Kirby]

You can also get in the habit of placing the rvalue (or constant value)
on the left of a comparison expression:

if (0 == myVar)
{
...
}

Now the code won't compile if a = replaces the ==.

However this is an incomplete solution (you don't always have a non-lvalue
available) that results in less readable and less consistent code. Many
compilers will diagnose this given suitable options and there are other
"lint" tools available which will do so. This is much more relaible than
source tricks like that above and is a much better approach.

Lawrence

 

[Eric Sosman]

Now, all I have to do is somehow guarantee that all if statements have
a constant.

if (ugly + 0 = bletcherous) ...

 

[Emmanuel Delahaye]

What do you mean by "dataflow analysing"? Thanks!

It's a analysis algorithm that is applied to the code in order to track
things like the use of uninitialized data.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

I once asked an expert COBOL programmer, how to
declare local variables in COBOL, the reply was:
"what is a local variable?"

 

[CBFalconer]

.... snip ...


Also, this is semantically the wrong message. You don't want to
inspect EOF, and see if its current value is that of ch; you want
to know whether the current character is End-Of-File.

I think the word ordering is only unusual to native English
speakers, and we can get used to it.

EOF, if that is the value of ch, then ....
else BLAH, if that is the value of ch, then ....

 

[Kenny McCormack]

However this is an incomplete solution (you don't always have a non-lvalue
available) that results in less readable and less consistent code. Many
compilers will diagnose this given suitable options and there are other
"lint" tools available which will do so. This is much more relaible than
source tricks like that above and is a much better approach.

Lawrence

Wow. For once, I agree with Lawrence Kirby.
Well done, sir.

 

[Greg]

However this is an incomplete solution (you don't always have a non-lvalue
available) that results in less readable and less consistent code. Many
compilers will diagnose this given suitable options and there are other
"lint" tools available which will do so. This is much more relaible than
source tricks like that above and is a much better approach.

Lawrence

Absolutely, switching the left and right sides of an equality test as
it is conventionally written makes the expression less readable [until
the pattern becomes familiar]. The more readable the code, the more
likely its errors will be overlooked. "Readable" text describes text
that fits a familiar pattern, and which the brain can read faster
because it can skip many of the words by filling in their most likely
form and meaning. In this case an assignment expression can "read" like
an equality test, so the mistake can go undetected.

Note that switching the right and left operands makes the expression no
less understandable. Source code should be written to be
understandable, posts to USENET should be written to be readable. The
computer does not execute a source program as if it were reading a
novel. So a person reading the source of a program, should not read it
in the same way as they would a novel.

There are benefits to a less readable syntax even in the case when the
left hand expression is not a constant. The brain will have to scan the
expression much more closely (because it does not fit the expected
pattern), in order to parse it. And the closer scrutiny is more likely
to catch an assignment error.

The motivation to write readable code is to lighten the workload on its
reader; but it does so by essentially inviting the reader to gloss over
its mistakes. The computer executing the code will overlook no error;
so the reader should approach the source code as the computer does and
have to examine each line to understand its meaning. Because whether a
set of source code is readable or not, matters far less than whether it
is understandably correct.

Greg