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

[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

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.[/QUOTE]

Very interesting. (Rest of very eloquent defense of your very clearly
non-mainstream position - deleted only to save space)

Mainstream thought today is that source code should be *readable* by humans
and *understandable* by computers. This is so that you can spend less on
humans.

My $.02: People who maintain the converse of your (Greg's) position should
not be programming in C. (*)

(*) Read this carefully - this is not a typo.

P.S. If you really care about this "problem" (which hasn't been a problem
for me since about the 3rd week of my time as a C programmer), just do:

#define EQUALS ==

and use that for equality tests.

P.P.S. This discussion is antique anyway, since every (*) C compiler since
about 1989 has issued a warning about this (yes, sometimes you do have to
find the right compiler option for it)

(*) Don't bother writing in with obscure exceptions to this generalization.

 

[Walter Roberson]

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.

Say, in your opinion, which font is best for your APL programs?

 

[Richard Bos]

I think the word ordering is only unusual to native English
speakers,

*looks at headers*

Erm, I don't think so...

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

In Japanese or Forth, maybe I could. Not in C, though.

Richard

 

[Rob Thorpe]

Hi,

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

It's very useful to have an editor that warns about this.

For example, if you use GNU Emacs and enable cwarn-mode it will
highlight single "=" signs in if-statements in bright red.

This is very useful, but can be irritating if you use them
deliberately.

 

[akarl]

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

Use a lint tool such as Splint (http://www.splint.org/).

 

[Kenny McCormack]

It's very useful to have an editor that warns about this.

For example, if you use GNU Emacs and enable cwarn-mode it will
highlight single "=" signs in if-statements in bright red.

This is very useful, but can be irritating if you use them
deliberately.

I must say I really don't understand this thread at all.
I mean, I misspell printf more often than I use = for == or vice versa.

And my compiler prompts warns me of either error quite nicely thank you.

 

[Alan Balmer]

Well, those that don't can usually legitimately use the '=' in
place of '=='.

Weak justification of your practices is not sufficient reason to make
code less obvious. Unless you're practicing for the IOCCC.

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.

Nonsense. Issuing a warning for all cases, as many (most?) compilers
can be asked to do, is no more likely to lead to this than your notion
of issuing the warning for only some cases.

 

[Alan Balmer]

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.

So, once the pattern becomes familiar, it's just as likely the error
will be overlooked? Why bother?

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

Nope. As you say, the brain recognizes patterns. "A = B" is a
different pattern from "A == B", and sticks out like the proverbial
sore thumb.

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.

If this actually means anything, I think you should present it to
Donald Knuth ;-)

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.

Or, perhaps, allow the computer to do the job?

 

[Alan Balmer]

It's very useful to have an editor that warns about this.

For example, if you use GNU Emacs and enable cwarn-mode it will
highlight single "=" signs in if-statements in bright red.

This is very useful, but can be irritating if you use them
deliberately.

Another reason not to use them deliberately.

 

[Kenny McCormack]

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.

Nonsense. Issuing a warning for all cases, as many (most?) compilers
can be asked to do, is no more likely to lead to this than your notion
of issuing the warning for only some cases.[/QUOTE]

Whoosh!

 

[Alan Balmer]

Nonsense. Issuing a warning for all cases, as many (most?) compilers
can be asked to do, is no more likely to lead to this than your notion
of issuing the warning for only some cases.

Whoosh![/QUOTE]

Not exactly, but jokes don't improve the notion, either, and the
attempted distraction is temporary - he'll be making the same old
suggestion, followed by the same old argument, again soon.

 

[CBFalconer]

.... snip ...

Weak justification of your practices is not sufficient reason to
make code less obvious. Unless you're practicing for the IOCCC.

I often have a bunch of functions that signal success with 0 or
NULL, and they can be used in code similar to the following:

if (thing1 = function1(whatever)) {
dorecoveryfromfuncone(thing1);
}
else if (thing2 = function2(otherstuff)) {
dorecoverfromfunctwo(thing2);
}
else if (....) {
}
else { /* all the preconditions are satisfied */
doyourstuff(feet);
}

 

[CBFalconer]

.... snip ...

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.

So, once the pattern becomes familiar, it's just as likely the
error will be overlooked? Why bother?

By the reader. The compiler, being less easily distracted, will
notice.

 

[Cool Guy]

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

Why not just pay attention to what you write?

 

[websnarf]

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

Making a mistake by switching the from and to variables about a single
"=" is rare. When testing the assignment of a variable I usually write
it as:

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

since the compiler will have no trouble removing the "0 !=" internally.

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.

gcc with -Wall -ansi -pedantic seems to be perfectly happy with the
form I suggest. So do all the other 4 main compilers that I use with
their warnings set at maximum.

 

[websnarf]

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

Not that I would ever defend CBFalconer for any reason, but why do you
feel the need to project this false image about what he is or is not
disused about? If you people all insist on not casting malloc(), do
you take that to mean that you will all therefore tend to forget
include necessary .h files in general?

Also, this is semantically the wrong message. You don't want to inspect
EOF, and see if its current value is that of ch;

Yes he does.

[...] you want to know whether the current character is End-Of-File.

Yes of course. Because they are the same thing. If you don't realize
or internalize this simple idea, then your mind is simply unsuitable
for computer programming and you should consider another line of work.

 

[Richard Bos]

What advantage does this have over the more readable

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

It makes the user feel all superior inside.

Richard

 

[Lawrence Kirby]

Making a mistake by switching the from and to variables about a single
"=" is rare. When testing the assignment of a variable I usually write
it as:

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

What advantage does this have over the more readable

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

?

Lawrence

 

[Randy Howard]

Not that I would ever defend CBFalconer for any reason,

Harboring a grudge is so uncivilized. If he's right, he's
right.

[...] you want to know whether the current character is End-Of-File.

Yes of course. Because they are the same thing. If you don't realize
or internalize this simple idea, then your mind is simply unsuitable
for computer programming and you should consider another line of work.

And here we have an exposition on exactly why so many people
have Paul's picture on the wall next to their mother's. He is
so loved, because of his kindness, understanding, and respect of
others.

 

[CBFalconer]

CBFalconer <[email protected]> wrote:

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

Yes he does.

[...] you want to know whether the current character is End-Of-File.

Yes of course. Because they are the same thing. If you don't
realize or internalize this simple idea, then your mind is simply
unsuitable for computer programming and you should consider another
line of work.

Well, Hsieh and I actually agree on something fundamental. Maybe
we can now drop the personalities and super-sensitivity. This has
something to do with olives.