By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,098 Members | 1,950 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,098 IT Pros & Developers. It's quick & easy.

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

P: n/a
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

Nov 15 '05 #1
Share this Question
Share on Google+
65 Replies


P: n/a
Pe*******@gmail.com wrote on 23/06/05 :
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?"

Nov 15 '05 #2

P: n/a


Emmanuel Delahaye wrote:
Pe*******@gmail.com wrote on 23/06/05 :
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.


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

Nov 15 '05 #3

P: n/a
"Pe*******@gmail.com" wrote:

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 */
}

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 15 '05 #4

P: n/a
In article <42***************@yahoo.com>, cb********@yahoo.com says...
"Pe*******@gmail.com" wrote:

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


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.

--
Randy Howard (2reply remove FOOBAR)
"I don't really care about being right you know,
I just care about success." --Steve Jobs
Nov 15 '05 #5

P: n/a
Pe*******@gmail.com wrote:
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?

--
Stan
Nov 15 '05 #6

P: n/a
Stan R. wrote:
Pe*******@gmail.com wrote:
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?


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

P: n/a
On Thu, 23 Jun 2005 22:02:52 GMT, CBFalconer <cb********@yahoo.com>
wrote:
"Pe*******@gmail.com" wrote:

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 */
}


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

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 15 '05 #8

P: n/a


Alfred Z. Newmane wrote:
Stan R. wrote:
Pe*******@gmail.com wrote:
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?


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

Nov 15 '05 #9

P: n/a
* Greg:


Alfred Z. Newmane wrote:
Stan R. wrote:
Pe*******@gmail.com wrote:
> 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?


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


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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Nov 15 '05 #10

P: n/a
Alan Balmer wrote:
CBFalconer <cb********@yahoo.com> wrote:
"Pe*******@gmail.com" wrote:

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 */
}


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.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 15 '05 #11

P: n/a
Alfred Z. Newmane wrote:
Stan R. wrote:
Pe*******@gmail.com wrote:
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?


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

Nov 15 '05 #12

P: n/a
>>You can also get in the habit of placing the rvalue (or constant value)
on the left of a comparison expression:
if (0 == myVar)

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'? ;-]
Nov 15 '05 #13

P: n/a
CBFalconer <cb********@yahoo.com> wrote:
"Pe*******@gmail.com" wrote:

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.


....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
Nov 15 '05 #14

P: n/a
On Thu, 23 Jun 2005 18:12:55 -0700, Greg wrote:


Alfred Z. Newmane wrote:
Stan R. wrote:
> Pe*******@gmail.com wrote:
>> 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?


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


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
Nov 15 '05 #15

P: n/a


Alan Balmer wrote:
On Thu, 23 Jun 2005 22:02:52 GMT, CBFalconer <cb********@yahoo.com>
wrote:

"Pe*******@gmail.com" wrote:
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 */
}

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


if (ugly + 0 = bletcherous) ...

--
Er*********@sun.com

Nov 15 '05 #16

P: n/a
Pe*******@gmail.com wrote on 23/06/05 :
Emmanuel Delahaye wrote:
Pe*******@gmail.com wrote on 23/06/05 :
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.


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

Nov 15 '05 #17

P: n/a
Richard Bos wrote:
CBFalconer <cb********@yahoo.com> wrote:
.... snip ...
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.


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

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 15 '05 #18

P: n/a
In article <pa****************************@netactive.co.uk> ,
Lawrence Kirby <lk****@netactive.co.uk> wrote:
On Thu, 23 Jun 2005 18:12:55 -0700, Greg wrote:


Alfred Z. Newmane wrote:
Stan R. wrote:
> Pe*******@gmail.com wrote:
>> 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?

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


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.

Nov 15 '05 #19

P: n/a


Lawrence Kirby wrote:
On Thu, 23 Jun 2005 18:12:55 -0700, Greg wrote:


Alfred Z. Newmane wrote:
Stan R. wrote:
> Pe*******@gmail.com wrote:
>> 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?

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


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

Nov 15 '05 #20

P: n/a
In article <11*********************@o13g2000cwo.googlegroups. com>,
Greg <gr****@pacbell.net> wrote:
....
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.


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.

Nov 15 '05 #21

P: n/a
In article <11*********************@o13g2000cwo.googlegroups. com>,
Greg <gr****@pacbell.net> wrote:
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?
--
'The short version of what Walter said is "You have asked a question
which has no useful answer, please reconsider the nature of the
problem you wish to solve".' -- Tony Mantler
Nov 15 '05 #22

P: n/a
CBFalconer <cb********@yahoo.com> wrote:
Richard Bos wrote:
CBFalconer <cb********@yahoo.com> wrote:
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.


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
Nov 15 '05 #23

P: n/a
Pe*******@gmail.com wrote:
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.

Nov 15 '05 #24

P: n/a
Pe*******@gmail.com wrote:
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/).
Nov 15 '05 #25

P: n/a
In article <11**********************@o13g2000cwo.googlegroups .com>,
Rob Thorpe <ro***********@antenova.com> wrote:
Pe*******@gmail.com wrote:
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.


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.

Nov 15 '05 #26

P: n/a
On Fri, 24 Jun 2005 02:27:12 GMT, CBFalconer <cb********@yahoo.com>
wrote:
Alan Balmer wrote:
CBFalconer <cb********@yahoo.com> wrote:
"Pe*******@gmail.com" wrote:

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 */
}
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 '=='.


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.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 15 '05 #27

P: n/a
On 26 Jun 2005 06:52:00 -0700, "Greg" <gr****@pacbell.net> wrote:


Lawrence Kirby wrote:
On Thu, 23 Jun 2005 18:12:55 -0700, Greg wrote:
>
>
> Alfred Z. Newmane wrote:
>> Stan R. wrote:
>> > Pe*******@gmail.com wrote:
>> >> 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?
>>
>> 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 ==.
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?
Because whether a
set of source code is readable or not, matters far less than whether it
is understandably correct.

Greg


--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 15 '05 #28

P: n/a
On 27 Jun 2005 02:55:20 -0700, "Rob Thorpe"
<ro***********@antenova.com> wrote:
Pe*******@gmail.com wrote:
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.


Another reason not to use them deliberately.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 15 '05 #29

P: n/a
In article <j6********************************@4ax.com>,
Alan Balmer <al******@spamcop.net> wrote:
....
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.


Whoosh!

Nov 15 '05 #30

P: n/a
On Mon, 27 Jun 2005 16:21:38 GMT, ga*****@yin.interaccess.com (Kenny
McCormack) wrote:
In article <j6********************************@4ax.com>,
Alan Balmer <al******@spamcop.net> wrote:
...
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.


Whoosh!


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.

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 15 '05 #31

P: n/a
Alan Balmer wrote:
CBFalconer <cb********@yahoo.com> wrote:
Alan Balmer wrote:
CBFalconer <cb********@yahoo.com> wrote:

.... snip ...

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.


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.


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);
}

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 15 '05 #32

P: n/a
Alan Balmer wrote:
"Greg" <gr****@pacbell.net> wrote:

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

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 15 '05 #33

P: n/a
"Pe*******@gmail.com" <Pe*******@gmail.com> wrote:
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?
Nov 15 '05 #34

P: n/a
Randy Howard wrote:
In article <42***************@yahoo.com>, cb********@yahoo.com says...
"Pe*******@gmail.com" wrote:

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


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.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Nov 15 '05 #35

P: n/a
Richard Bos wrote:
CBFalconer <cb********@yahoo.com> wrote:
"Pe*******@gmail.com" wrote:

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.


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


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.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Nov 15 '05 #36

P: n/a
On Wed, 29 Jun 2005 02:16:37 -0700, websnarf wrote:
Randy Howard wrote:
In article <42***************@yahoo.com>, cb********@yahoo.com says...
> "Pe*******@gmail.com" wrote:
> >
> > 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) ....


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


What advantage does this have over the more readable

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

?

Lawrence

Nov 15 '05 #37

P: n/a
Lawrence Kirby <lk****@netactive.co.uk> wrote:
On Wed, 29 Jun 2005 02:16:37 -0700, websnarf wrote:
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) ...


It makes the user feel all superior inside.

Richard
Nov 15 '05 #38

P: n/a
On Wed, 29 Jun 2005 04:24:42 -0500, we******@gmail.com wrote
(in article
<11**********************@o13g2000cwo.googlegroups .com>):
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.

:-)
--
Randy Howard

Nov 15 '05 #39

P: n/a
we******@gmail.com wrote:
Richard Bos wrote:
CBFalconer <cb********@yahoo.com> wrote:

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


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.

--
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Nov 15 '05 #40

P: n/a
In article <11**********************@o13g2000cwo.googlegroups .com>,
Pe*******@gmail.com <Pe*******@gmail.com> wrote:

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.
--
7842++
Nov 15 '05 #41

P: n/a

"Anonymous 7843" <an******@example.com> wrote in message
news:v7Bwe.1338$HV1.203@fed1read07...
In article <11**********************@o13g2000cwo.googlegroups .com>,
Pe*******@gmail.com <Pe*******@gmail.com> wrote:

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:

<snip> 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):
You would want to compile with the -Wparentheses command line option.

Nov 15 '05 #42

P: n/a
Lawrence Kirby wrote:
On Wed, 29 Jun 2005 02:16:37 -0700, websnarf wrote:
Randy Howard wrote:
In article <42***************@yahoo.com>, cb********@yahoo.com says...
> "Pe*******@gmail.com" wrote:
> >
> > 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) ....

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


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)

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Nov 15 '05 #43

P: n/a
In article <F2*******************@newshog.newsread.com>,
Mark <so***@localbar.com> wrote:
trn's article tree for this thread, so far:

<snip>
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):
You would want to compile with the -Wparentheses command line option.


I killfile all crossposts...that's why I didn't see his message.
I should have double checked before making the pronouncement.
Sorry.
--
7842++
Nov 15 '05 #44

P: n/a
<we******@gmail.com> wrote in message
news:11********************@g49g2000cwa.googlegrou ps.com...
Lawrence Kirby wrote:
On Wed, 29 Jun 2005 02:16:37 -0700, websnarf wrote:
> Randy Howard wrote:
>> In article <42***************@yahoo.com>, cb********@yahoo.com says...
>> > "Pe*******@gmail.com" wrote:
>> > >
>> > > 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) ....
>>
>> 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)) ...
What advantage does this have over the more readable

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


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

Nov 15 '05 #45

P: n/a
Mark wrote:
<we******@gmail.com> wrote in message
news:11********************@g49g2000cwa.googlegrou ps.com...
Lawrence Kirby wrote:
On Wed, 29 Jun 2005 02:16:37 -0700, websnarf wrote:

Randy Howard wrote:

>In article <42***************@yahoo.com>, cb********@yahoo.com says...
>
>>"Pe*******@gmail.com" wrote:
>>
>>>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) ....
>
>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)) ...

What advantage does this have over the more readable

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


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


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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Nov 15 '05 #46

P: n/a
"Michael Mair" <Mi**********@invalid.invalid> wrote in message
news:3i************@individual.net...
Mark wrote:
<we******@gmail.com> wrote in message
news:11********************@g49g2000cwa.googlegrou ps.com...
Lawrence Kirby wrote:

On Wed, 29 Jun 2005 02:16:37 -0700, websnarf wrote:

>Randy Howard wrote:
>
>>In article <42***************@yahoo.com>, cb********@yahoo.com says...
>>
>>>"Pe*******@gmail.com" wrote:
>>>
>>>>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) ....
>>
>>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)) ...

What advantage does this have over the more readable

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

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


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>

Nov 15 '05 #47

P: n/a
Lawrence Kirby wrote:
websnarf wrote:

.... snip ...

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


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

--
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Nov 15 '05 #48

P: n/a
Mark wrote:
"Michael Mair" <Mi**********@invalid.invalid> wrote in message
news:3i************@individual.net...
Mark wrote:
<we******@gmail.com> wrote in message
news:11********************@g49g2000cwa.googleg roups.com...
Lawrence Kirby wrote:
>On Wed, 29 Jun 2005 02:16:37 -0700, websnarf wrote:
>
>
>>Randy Howard wrote:
>>
>>
>>>In article <42***************@yahoo.com>, cb********@yahoo.com says...
>>>
>>>
>>>>"Pe*******@gmail.com" wrote:
>>>>
>>>>
>>>>>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) ....
>>>
>>>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)) ...
>
>What advantage does this have over the more readable
>
> if ((a = b) != 0) ...

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


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>


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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Nov 15 '05 #49

P: n/a
On Wed, 29 Jun 2005 12:10:38 -0700, websnarf wrote:
Lawrence Kirby wrote:
On Wed, 29 Jun 2005 02:16:37 -0700, websnarf wrote:
> Randy Howard wrote:
>> In article <42***************@yahoo.com>, cb********@yahoo.com says...
>> > "Pe*******@gmail.com" wrote:
>> > >
>> > > 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) ....
>>
>> 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)) ...
What advantage does this have over the more readable

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


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


Nov 15 '05 #50

65 Replies

This discussion thread is closed

Replies have been disabled for this discussion.