Did you know?

[Vijay Kumar R Zanvar]

Did you know that the following if statement is semantically
right, but could logically be wrong?

if ( i = 2 )
{
/* do something */
}

Tip:

The compiler may only produce a waring: "Possibly incorrect
assignment", but we may ignore it. To avoid such a mistake,
just reverse the two identifiers.

if ( 2 == i )
{
/* do something */
}

If '==' is replaced by an '=', the compiler will give an error
saying "Lvalue required".

--
"When you will be pleased to dine, Mr. Homles?" asked Mrs Hudson,
the landlady, curiosly.
"At seven thirty, the day after tomorrow." said he invovled in his work.

[Joona I Palaste]

Vijay Kumar R Zanvar <vi*****@hotmail.com> scribbled the following:

Did you know that the following if statement is semantically
right, but could logically be wrong? if ( i = 2 )
{
/* do something */
} Tip: The compiler may only produce a waring: "Possibly incorrect
assignment", but we may ignore it. To avoid such a mistake,
just reverse the two identifiers. if ( 2 == i )
{
/* do something */
} If '==' is replaced by an '=', the compiler will give an error
saying "Lvalue required".

Yes, we did know all this. But thanks for letting us know anyway.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"I am looking for myself. Have you seen me somewhere?"
- Anon

[Vijay Kumar R Zanvar]

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bl**********@oravannahka.helsinki.fi...

Vijay Kumar R Zanvar <vi*****@hotmail.com> scribbled the following:

^^^^^^^^

Did I scribble?

Did you know that the following if statement is semantically
right, but could logically be wrong?
[...]
If '==' is replaced by an '=', the compiler will give an error
saying "Lvalue required".

Yes, we did know all this. But thanks for letting us know anyway.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\

I suppose it would be fun working with you, Mr. Palaste. You must be a
comedian!!

--
"We approached the case, you remember Watson," said
Mr. Homles, "with an absolutely blank mind, which is
always an advantage."

[Andreas Kahari]

In article <bl************@ID-203837.news.uni-berlin.de>, Vijay Kumar R Zanvar wrote:

Did you know that the following if statement is semantically
right, but could logically be wrong?

if ( i = 2 )
{
/* do something */
}

Yes, it's a well known fact and it's in the FAQ:

http://www.eskimo.com/~scs/C-faq/q17.4.html
--
Andreas Kähäri

[Noah Roberts]

Vijay Kumar R Zanvar wrote:

if ( 2 == i )
{
/* do something */
}

What if 2 != i but i == 2, ever thought of that?

BTW, did you know that the above code doesn't do anything even if 2 ==
i? I wonder what happens if i == 2 though...

NR

[Goran Larsson]

In article <bl************@ID-203837.news.uni-berlin.de>,
Vijay Kumar R Zanvar <vi*****@hotmail.com> wrote:

Did you know that the following if statement is semantically
right, but could logically be wrong?

if ( i = 2 )
{
/* do something */
}

Did you know that the following if statement is semantically
right, but could logically be wrong?

if ( i = k )
{
/* do something */
}

--
Göran Larsson http://www.mitt-eget.com/

[Robert Stankowic]

"Noah Roberts" <nr******@dontemailme.com> schrieb im Newsbeitrag
news:bl**********@quark.scn.rain.com...

Vijay Kumar R Zanvar wrote:

if ( 2 == i )
{
/* do something */
}

What if 2 != i but i == 2, ever thought of that?

BTW, did you know that the above code doesn't do anything even if 2 ==
i? I wonder what happens if i == 2 though...

What, if you replace "==" with "is equal to" as well as "!=" with "is
unequal to" and "i" with "the value contained in a variable named i" ?
Robert

[Ravi]

On Mon, 29 Sep 2003 08:30:12 GMT, ho*@invalid.invalid (Goran
Larsson) wrote:

Did you know that the following if statement is semantically
right, but could logically be wrong?

if ( i = k )
{
/* do something */
}

On second thoughts it could be correct. If you want the loop
to execute with i assigned to the value of k only when k is
not zero you might as well use that form.

Sorter than:
if (k!=0)
{
i=k;
/* do everything ;)*/
}
--
main(){char s[40]="sbwjAeftqbnnfe/dpn!ps!CSbwjACjhgppu/dpn";
int i;for(i=0;i<39;putchar(s[i++]-1));return 0;}

[Jirka Klaue]

Noah Roberts wrote:

Vijay Kumar R Zanvar wrote:

if ( 2 == i )
{
/* do something */
}

What if 2 != i but i == 2, ever thought of that?

Well, ...

#define i i, 2

Jirka

[Al Bowers]

Vijay Kumar R Zanvar wrote:

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bl**********@oravannahka.helsinki.fi...

Vijay Kumar R Zanvar <vi*****@hotmail.com> scribbled the following:

^^^^^^^^

Did I scribble?

Did you know that the following if statement is semantically
right, but could logically be wrong?

[...]

If '==' is replaced by an '=', the compiler will give an error
saying "Lvalue required".

Yes, we did know all this. But thanks for letting us know anyway.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\

I suppose it would be fun working with you, Mr. Palaste. You must be a
comedian!!

Perhaps dry humor given the fact that everyone should know
this if they read the FAG.
See question 17.4
http://www.eskimo.com/~scs/C-faq/q17.4.html

[Noah Roberts]

Ravi wrote:

On Mon, 29 Sep 2003 08:30:12 GMT, ho*@invalid.invalid (Goran
Larsson) wrote:

Did you know that the following if statement is semantically
right, but could logically be wrong?

if ( i = k )
{
/* do something */
}

Sorter than:
if (k!=0)
{
i=k;
/* do everything ;)*/
}

Except in the first i is always given the value k.

NR

[James Hu]

Joona I Palaste <pa*****@cc.helsinki.fi> wrote in message news:<bl**********@oravannahka.helsinki.fi>...

Vijay Kumar R Zanvar <vi*****@hotmail.com> scribbled the following:

Tip:

if ( 2 == i )
{
/* do something */
}

If '==' is replaced by an '=', the compiler will give an error
saying "Lvalue required".

Yes, we did know all this. But thanks for letting us know anyway.

In fact, it is in the C-faq.

http://www.eskimo.com/~scs/C-faq/q17.4.html

"Read the C-faq. It's better up here!"

-- James

[Richard Bos]

"Vijay Kumar R Zanvar" <vi*****@hotmail.com> wrote:

Tip:

The compiler may only produce a waring: "Possibly incorrect
assignment", but we may ignore it. To avoid such a mistake,
just reverse the two identifiers.

if ( 2 == i )
{
/* do something */
}

Did you know that this is a stupid trick to rely on, because it makes
the code less clear, doesn't help you in all too many situations, and
therefore _will_ bite you sooner or later? At least the real solution,
which is being aware of the problem, will help you debug your code when
you _do_ make this mistake.

Richard

[Mike Wahler]

"Vijay Kumar R Zanvar" <vi*****@hotmail.com> wrote in message
news:bl************@ID-203837.news.uni-berlin.de...

Did you know
Of course we know.
that the following if statement is semantically
right, but could logically be wrong?

if ( i = 2 )
{
/* do something */
}

Tip:

The compiler may only produce a waring: "Possibly incorrect
assignment", but we may ignore it. To avoid such a mistake,
just reverse the two identifiers.

if ( 2 == i )
{
/* do something */
}

If '==' is replaced by an '=', the compiler will give an error
saying "Lvalue required".

This issue has been discussed many, many, many times
here, if you'd taken the time to check old posts.
Some folks use the 2 == i form, others don't.

Also note that sometimes the = (assignment) is indeed
what the coder wants as in e.g.

char *p;
if(p = malloc(100))
/* malloc succeeded */
-Mike

[Tristan Miller]

Greetings.

In article <bl************@ID-203837.news.uni-berlin.de>, Vijay Kumar R
Zanvar wrote:

The compiler may only produce a waring: "Possibly incorrect
assignment", but we may ignore it. To avoid such a mistake,
just reverse the two identifiers.

Wouldn't a better way of avoiding such a mistake be not to ignore compiler
warnings in the first place?

--
_
_V.-o Tristan Miller [en,(fr,de,ia)] >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= <> In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you

[Ashish]

"Vijay Kumar R Zanvar" <vi*****@hotmail.com> wrote in message
news:bl************@ID-203837.news.uni-berlin.de...

Did you know that the following if statement is semantically
right, but could logically be wrong?

if ( i = 2 )
{
/* do something */
}

Tip:

The compiler may only produce a waring: "Possibly incorrect
assignment", but we may ignore it. To avoid such a mistake,
just reverse the two identifiers.

if ( 2 == i )
{
/* do something */
}

If '==' is replaced by an '=', the compiler will give an error
saying "Lvalue required".

--
"When you will be pleased to dine, Mr. Homles?" asked Mrs Hudson,
the landlady, curiosly.
"At seven thirty, the day after tomorrow." said he invovled in his work.

Are you still living in the 19th century? This has been discussed millions
of times.

[Richard Heathfield]

Richard Bos wrote:

"Vijay Kumar R Zanvar" <vi*****@hotmail.com> wrote:

Tip:

The compiler may only produce a waring: "Possibly incorrect
assignment", but we may ignore it. To avoid such a mistake,
just reverse the two identifiers.

if ( 2 == i )
{
/* do something */
}
Did you know that this is a stupid trick to rely on,

It's stupid to rely on it, but not stupid to use it.
because it makes
the code less clear,
The expression isn't unclear /at all/, and only an expert could have the
slightest doubt about it. :-)
doesn't help you in all too many situations,
Not casting malloc doesn't help you in all too many situations, either (such
as in code where malloc is not used, for example). That doesn't mean I'm
about to start casting malloc, though.
and
therefore _will_ bite you sooner or later?
Nope. It doesn't bite, as long as you don't rely on it. It's just another
tool in the box.
At least the real solution,
which is being aware of the problem, will help you debug your code when
you _do_ make this mistake.

It is important to be aware of the problem. That doesn't mean you shouldn't
use the compiler to help you avoid it on occasion.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Neil Cerutti]

In article <bl************@ID-169908.news.uni-berlin.de>, Al
Bowers wrote:

Vijay Kumar R Zanvar wrote:

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bl**********@oravannahka.helsinki.fi...

Vijay Kumar R Zanvar <vi*****@hotmail.com> scribbled the following: ^^^^^^^^

Did I scribble?

Did you know that the following if statement is semantically
right, but could logically be wrong?

[...]

Yes, we did know all this. But thanks for letting us know anyway.

--

I suppose it would be fun working with you, Mr. Palaste. You
must be a comedian!!

Perhaps dry humor given the fact that everyone should know
this if they read the FAG.

The what!?
See question 17.4
http://www.eskimo.com/~scs/C-faq/q17.4.html

Oh.

I find it's useful to write QAF backwards to how it's usually
written (Questions Asked Frequently) to avoid this type of
error. That way, if you miswrite G instead of Q, it will be
meaningless instead of sort of amusing. ;-)

--
Neil Cerutti

[Mike Wahler]

"Neil Cerutti" <ho*****@yahoo.com> wrote in message
news:bl************@ID-60390.news.uni-berlin.de...

In article <bl************@ID-169908.news.uni-berlin.de>, Al
Bowers wrote:

Vijay Kumar R Zanvar wrote:

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bl**********@oravannahka.helsinki.fi...

Vijay Kumar R Zanvar <vi*****@hotmail.com> scribbled the following:
^^^^^^^^

Did I scribble?
>Did you know that the following if statement is semantically
>right, but could logically be wrong?

[...]
Yes, we did know all this. But thanks for letting us know anyway.

--
I suppose it would be fun working with you, Mr. Palaste. You
must be a comedian!!

Perhaps dry humor given the fact that everyone should know
this if they read the FAG.

The what!?

See question 17.4
http://www.eskimo.com/~scs/C-faq/q17.4.html

Oh.

I find it's useful to write QAF backwards to how it's usually
written (Questions Asked Frequently) to avoid this type of
error. That way, if you miswrite G instead of Q, it will be
meaningless instead of sort of amusing. ;-)

It would be a gaffe (GAF) :-)

-Mike

[CBFalconer]

Richard Bos wrote:

"Vijay Kumar R Zanvar" <vi*****@hotmail.com> wrote:

The compiler may only produce a waring: "Possibly incorrect
assignment", but we may ignore it. To avoid such a mistake,
just reverse the two identifiers.

if ( 2 == i )
{
/* do something */
}

Did you know that this is a stupid trick to rely on, because it
makes the code less clear, doesn't help you in all too many
situations, and therefore _will_ bite you sooner or later? At
least the real solution, which is being aware of the problem,
will help you debug your code when you _do_ make this mistake.

We have been around this before. Clarity is in the eye of the
beholder. I consider anything that catches silly errors
beneficial. This is an error that can escape code review very
easily.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[nrk]

Vijay Kumar R Zanvar wrote:

Did you know that the following if statement is semantically
right, but could logically be wrong?

if ( i = 2 )
{
/* do something */
}

Tip:

The compiler may only produce a waring: "Possibly incorrect
assignment", but we may ignore it. To avoid such a mistake,
just reverse the two identifiers.

Did you know that only a moron (talk about fools rushing in...) would
ignore a compiler diagnostic without giving it considerable attention
and thought? Did you also know that such morons richly deserve the
demons that fly out of their nasal cavities?
if ( 2 == i )
{
/* do something */
}

If '==' is replaced by an '=', the compiler will give an error
saying "Lvalue required".

Looks cute, but is highly counter-intuitive to me. The cognitive
dissonance it induces in me is sufficient to prevent me from using it ever.

-nrk.

[Chris Dollin]

CBFalconer wrote:

Richard Bos wrote:

"Vijay Kumar R Zanvar" <vi*****@hotmail.com> wrote:

> The compiler may only produce a waring: "Possibly incorrect
> assignment", but we may ignore it. To avoid such a mistake,
> just reverse the two identifiers.
>
> if ( 2 == i )
> {
> /* do something */
> }

Did you know that this is a stupid trick to rely on, because it
makes the code less clear, doesn't help you in all too many
situations, and therefore _will_ bite you sooner or later? At
least the real solution, which is being aware of the problem,
will help you debug your code when you _do_ make this mistake.

We have been around this before. Clarity is in the eye of the
beholder. I consider anything that catches silly errors
beneficial. This is an error that can escape code review very
easily.

I find it hard to believe that the bad code won't fail its tests,
though.

--
Chris "recent convert" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgrou...mp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambl...me_to_clc.html

[Keith Thompson]

Chris Dollin <ke**@hpl.hp.com> writes:

CBFalconer wrote:

Richard Bos wrote:

"Vijay Kumar R Zanvar" <vi*****@hotmail.com> wrote:

> The compiler may only produce a waring: "Possibly incorrect
> assignment", but we may ignore it. To avoid such a mistake,
> just reverse the two identifiers.
>
> if ( 2 == i )
> {
> /* do something */
> }

Did you know that this is a stupid trick to rely on, because it
makes the code less clear, doesn't help you in all too many
situations, and therefore _will_ bite you sooner or later? At
least the real solution, which is being aware of the problem,
will help you debug your code when you _do_ make this mistake.

We have been around this before. Clarity is in the eye of the
beholder. I consider anything that catches silly errors
beneficial. This is an error that can escape code review very
easily.

I find it hard to believe that the bad code won't fail its tests,
though.

Actually, I find it quite easy to believe. For example:

int result = how_many_widgets();

if (result = 1) {
/*
* Oh good, we have exactly 1 widget, go ahead and process it.
*/
process_single_widget();
}
else {
/*
* We don't have exactly 1 widget, something has gone horribly
* wrong. It's a good thing we checked the result so we can
* detect this error.
*/
fprintf(stderr, "Horrors, we have %d widget(s)\n", result);
exit(EXIT_FAILURE);
}

If the error escapes code review, it won't show up until something
goes horribly wrong and the program calls process_single_widget()
anyway.

Personally, I think the best solution is to make sure your code is
written and reviewed by people who know the difference between "=" and
"==". (Yeah, that's glib; I'd also require programmers to pay
attention to warnings.)

Actually, the *best* solution is to hop into a time machine and tell
Dennis Ritchie to use "=" for equality and ":=" for assignment, or
something similarly distinctive. It's a pity that time machines
invoke undefined behavior (real demons, real noses).

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Mike Wahler]

"Keith Thompson" <ks*@cts.com> wrote in message
news:lz************@cts.com...

Chris Dollin <ke**@hpl.hp.com> writes:

CBFalconer wrote:

Richard Bos wrote:
> "Vijay Kumar R Zanvar" <vi*****@hotmail.com> wrote:
>
> > The compiler may only produce a waring: "Possibly incorrect
> > assignment", but we may ignore it. To avoid such a mistake,
> > just reverse the two identifiers.
> >
> > if ( 2 == i )
> > {
> > /* do something */
> > }
>
> Did you know that this is a stupid trick to rely on, because it
> makes the code less clear, doesn't help you in all too many
> situations, and therefore _will_ bite you sooner or later? At
> least the real solution, which is being aware of the problem,
> will help you debug your code when you _do_ make this mistake.

We have been around this before. Clarity is in the eye of the
beholder. I consider anything that catches silly errors
beneficial. This is an error that can escape code review very
easily.

I find it hard to believe that the bad code won't fail its tests,
though.

Actually, I find it quite easy to believe. For example:

int result = how_many_widgets();

if (result = 1) {
/*
* Oh good, we have exactly 1 widget, go ahead and process it.
*/
process_single_widget();
}
else {
/*
* We don't have exactly 1 widget, something has gone horribly
* wrong. It's a good thing we checked the result so we can
* detect this error.
*/
fprintf(stderr, "Horrors, we have %d widget(s)\n", result);
exit(EXIT_FAILURE);
}

If the error escapes code review, it won't show up until something
goes horribly wrong and the program calls process_single_widget()
anyway.

Personally, I think the best solution is to make sure your code is
written and reviewed by people who know the difference between "=" and
"==". (Yeah, that's glib; I'd also require programmers to pay
attention to warnings.)

Actually, the *best* solution is to hop into a time machine and tell
Dennis Ritchie to use "=" for equality and ":=" for assignment, or
something similarly distinctive. It's a pity that time machines
invoke undefined behavior (real demons, real noses).

Another way (I wouldn't use it though) is:

#define eq ==

if(this eq that)
/* whatever */

-Mike

[Chris Dollin]

Keith Thompson wrote:

Chris Dollin <ke**@hpl.hp.com> writes:

CBFalconer wrote:

> Richard Bos wrote:
>> "Vijay Kumar R Zanvar" <vi*****@hotmail.com> wrote:
>>
>> > The compiler may only produce a waring: "Possibly incorrect
>> > assignment", but we may ignore it. To avoid such a mistake,
>> > just reverse the two identifiers.
>> >
>> > if ( 2 == i )
>> > {
>> > /* do something */
>> > }
>>
>> Did you know that this is a stupid trick to rely on, because it
>> makes the code less clear, doesn't help you in all too many
>> situations, and therefore _will_ bite you sooner or later? At
>> least the real solution, which is being aware of the problem,
>> will help you debug your code when you _do_ make this mistake.
>
> We have been around this before. Clarity is in the eye of the
> beholder. I consider anything that catches silly errors
> beneficial. This is an error that can escape code review very
> easily.
>

I find it hard to believe that the bad code won't fail its tests,
though.

Actually, I find it quite easy to believe. For example:

int result = how_many_widgets();

if (result = 1) {
/*
* Oh good, we have exactly 1 widget, go ahead and process it.
*/
process_single_widget();
}
else {
/*
* We don't have exactly 1 widget, something has gone horribly
* wrong. It's a good thing we checked the result so we can
* detect this error.
*/
fprintf(stderr, "Horrors, we have %d widget(s)\n", result);
exit(EXIT_FAILURE);
}

If the error escapes code review, it won't show up until something
goes horribly wrong and the program calls process_single_widget()
anyway.

If you want to write this code, then you want to test it, so you
need a test that enforces the situation where you have 17 widgets
and makes sure the error is detected, and that test will fail.

I agree that the `exit(1)` may cause a smidgin of difficulty; there
are ways round it - such as, in this horrible situation, log the
message and process any one of the widgets.

Or of course make it work for many widgets ...

--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgrou...mp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambl...me_to_clc.html

[Neil Cerutti]

In article <lz************@cts.com>, Keith Thompson wrote:

Chris Dollin <ke**@hpl.hp.com> writes:

I find it hard to believe that the bad code won't fail its
tests, though.

Actually, I find it quite easy to believe. For example:

int result = how_many_widgets();

if (result = 1) {
/*
* Oh good, we have exactly 1 widget, go ahead and process it.
*/
process_single_widget();
}
else {
/*
* We don't have exactly 1 widget, something has gone horribly
* wrong. It's a good thing we checked the result so we can
* detect this error.
*/
fprintf(stderr, "Horrors, we have %d widget(s)\n", result);
exit(EXIT_FAILURE);
}

If the error escapes code review, it won't show up until
something goes horribly wrong and the program calls
process_single_widget() anyway.

Personally, I think the best solution is to make sure your code
is written and reviewed by people who know the difference
between "=" and "==". (Yeah, that's glib; I'd also require
programmers to pay attention to warnings.)

Actually, the *best* solution is to hop into a time machine and
tell Dennis Ritchie to use "=" for equality and ":=" for
assignment, or something similarly distinctive. It's a pity
that time machines invoke undefined behavior (real demons, real
noses).

A syntax that doesn't look like an equation would be even harder
to screw up.

store(x, 12);

--
Neil Cerutti

[James Antill]

On Mon, 29 Sep 2003 19:16:18 +0000, Richard Heathfield wrote:

Richard Bos wrote:

because it makes
the code less clear,

The expression isn't unclear /at all/, and only an expert could have the
slightest doubt about it. :-)

Well personally find...

if (i == 1) {}
if ((i = 1)) {}

....much more readable/clear over...

if (1 == i) {}
if (i = 1) {}

....which is possibly what Richard meant, but then I quite happily _don't_
ignore warnings that my compiler gives me so I've never seen any advantage of
the later. And the former catches the problems the later doesn't.

--
James Antill -- ja***@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/

[Richard Heathfield]

[Got to love KNode. Its random crashes are so damn nostalgic. If this is my
second reply to James, I apologise in advance for that.]

James Antill wrote:

Well personally find...

if (i == 1) {}
if ((i = 1)) {}

...much more readable/clear over...

if (1 == i) {}
if (i = 1) {}
Do you find x == y clearer than y == x? If so, why? If not, why do you find
i == 1 clearer than 1 == i?
...which is possibly what Richard meant, but then I quite happily _don't_
ignore warnings that my compiler gives me so I've never seen any advantage
of the later.
if(i = 1) does /not/ require a diagnostic message, and indeed some
implementations do not issue a diagnostic message for it.
And the former catches the problems the later doesn't.

The extra parentheses do not suppress any required diagnostics, and do not
guarantee the generation of any extra diagnostics. You are relying on an
implementation-specific trick, which is fine, provided you remain locked
into your existing implementation.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Jeremy Yallop]

Richard Heathfield wrote:

Do you find x == y clearer than y == x? If so, why? If not, why do you find
i == 1 clearer than 1 == i?

"If Geraldine is seventeen..."
"If seventeen is Geraldine..."

In (most?) natural languages the variable is written first. "is" is
sometimes symmetric ("the morning star is the evening star"), but it's
by no means always so ("Cambridge is in Gloucestershire"); it often
denotes set membership rather than identity. C's equality and
relational operators are similar: (i == 4) and (i < 4) mean (to me)
something like:

i \in {x:x=4}
i \in {x:x<4}

i.e. a test for whether "i" is a member of a certain (statically)
well-defined set. (The question concerns the /current/ value of the
thing on the left, and questions about the current value of an
unchanging quantity are unnatural, to say the least.)

As an aside, this doesn't arise in practice, since I virtually never
use "==" in C. Tests for identity tend to get written using "!=",
tests for null with "if (x)", and tests for equality with switch/case.
Standard library functions that return non-zero values on failure
(time()) or use zero other than to indicate failure (setjmp(),
strcmp()) are probably the only circumstances in which "==" shows up
consistently in my code.

Jeremy.

[Arthur J. O'Dwyer]

On Thu, 2 Oct 2003, Richard Heathfield wrote:

James Antill wrote:

Well personally find...

if (i == 1) {}
if ((i = 1)) {}

...much more readable/clear over...

if (1 == i) {}
if (i = 1) {}

Do you find x == y clearer than y == x? If so, why? If not,
why do you find i == 1 clearer than 1 == i?

Obviously because one expresses the writer's intent more clearly.
It is a long-standing tradition at least in English-language
mathematical notation to put the variable on the left and the
value on the right, e.g.

If a \coprime p, then a^(p-1) \congruent 1 (mod p)

as opposed to the relatively sillier-looking

If a \coprime p, then 1 \congruent a^(p-1) (mod p)

As with other mathematical and scientific conventions, this one
has carried over into programming. Possibly also a factor is
the English grammatical pattern

"_He_ is Bob." answers the question "Who is _he_?"

"_X_ equals 1." answers the question "What is _X_?"

"1 equals _X_." seems to answer the question "What is 1?",
which is intuitively perceived as silly, since everyone (except
maybe a few experts ;-) already knows what 1 is -- it's 1!

I don't know of any languages that do the he-is-bob pattern
differently, so I'm confident that it's fairly universal.

-Arthur

[Keith Thompson]

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:
[...]

I don't know of any languages that do the he-is-bob pattern
differently, so I'm confident that it's fairly universal.

<YODA>Bob he is, hmmm?</YODA>

if (1 == x) reads (to me) like Yodaspeak.

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Richard Heathfield]

Arthur J. O'Dwyer wrote:

On Thu, 2 Oct 2003, Richard Heathfield wrote:

James Antill wrote:

>
> Well personally find...
>
> if (i == 1) {}
> if ((i = 1)) {}
>
> ...much more readable/clear over...
>
> if (1 == i) {}
> if (i = 1) {}
Do you find x == y clearer than y == x? If so, why? If not,
why do you find i == 1 clearer than 1 == i?

Obviously because one expresses the writer's intent more clearly.

Hmmm. If it's "obvious", how come I don't see it?
It is a long-standing tradition at least in English-language
mathematical notation to put the variable on the left and the
value on the right, e.g.
It's a long-standing tradition, at least in English-language mathematical
notation, for:

i = i + 1

to have no real solutions. But programmers don't hesitate to discard that
baggage when it suits them.

<snip>
Possibly also a factor is
the English grammatical pattern

"_He_ is Bob." answers the question "Who is _he_?"
This isn't the same concept as "is /this/ scalar value the same as /that/
scalar value?".

"_X_ equals 1." answers the question "What is _X_?"
It is just as valid IMHO to say that it answers the question "is the value
of _X_ equal to 1?"

"1 equals _X_." seems to answer the question "What is 1?",
See above.
which is intuitively perceived as silly, since everyone (except
maybe a few experts ;-)
<g>
already knows what 1 is -- it's 1!
But does it have the same value as X? I think we should be told.
I don't know of any languages that do the he-is-bob pattern
differently, so I'm confident that it's fairly universal.

I don't know of any conforming C compilers that don't issue a diagnostic for
if(1 = x), so I'm confident that it's fairly universal.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Richard Heathfield]

Jeremy Yallop wrote:

Richard Heathfield wrote:

Do you find x == y clearer than y == x? If so, why? If not, why do you
find i == 1 clearer than 1 == i?
"If Geraldine is seventeen..."
"If seventeen is Geraldine..."

<shrug> C is not English. In this case, by the way, it would be a rather
more accurate comparison if you were to write: "if seventeen is Geraldine's
age" and "if Geraldine's age is seventeen". In C:

if(girl->age == 17)

and

if(17 == girl->age)

In (most?) natural languages the variable is written first. "is" is
sometimes symmetric ("the morning star is the evening star"), but it's
by no means always so ("Cambridge is in Gloucestershire");
But that's a different question anyway (as I know you realise).
it often
denotes set membership rather than identity.

I think you'll find that the == operator denotes equality, not set
membership.

<snip>

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[robin.pain]

"Ashish" <as*****@hotmail.com> wrote in message news:<bl************@ID-75446.news.uni-berlin.de>...

"Vijay Kumar R Zanvar" <vi*****@hotmail.com> wrote in message
news:bl************@ID-203837.news.uni-berlin.de...
<snip>

Tip:

The compiler may only produce a waring: "Possibly incorrect
assignment", but we may ignore it. To avoid such a mistake,
just reverse the two identifiers.

if ( 2 == i )
{
/* do something */
}

If '==' is replaced by an '=', the compiler will give an error
saying "Lvalue required".

<snip>

Are you still living in the 19th century? This has been discussed millions
of times.

"If I've told you once, I've told you a million times, avoid hyperbole."

W.Saffire

[Preben Traerup]

[snip]

The compiler may only produce a waring: "Possibly incorrect
assignment", but we may ignore it. To avoid such a mistake,
just reverse the two identifiers.

For gcc add -Werror
and learn to fix stuff the hard way.

I said gcc and I became OT - sorry.

[Jeremy Yallop]

Richard Heathfield wrote:

<shrug> C is not English. In this case, by the way, it would be a rather
more accurate comparison if you were to write: "if seventeen is Geraldine's
age" and "if Geraldine's age is seventeen".
I don't want to belabour the point, but the former still sounds
unnatural to me.
I think you'll find that the == operator denotes equality, not set
membership.

It denotes value equality, yes, but a variable is not the same /kind/
of thing as a literal, which is why most people do not find "if (x == 1)"
and "if (1 == x)" equally readable, whichever they prefer.

Jeremy.

[ozbear]

On 2 Oct 2003 14:53:33 GMT, Neil Cerutti <ho*****@yahoo.com> wrote:

In article <lz************@cts.com>, Keith Thompson wrote:

Chris Dollin <ke**@hpl.hp.com> writes:

I find it hard to believe that the bad code won't fail its
tests, though.

Actually, I find it quite easy to believe. For example:
<snip example> If the error escapes code review, it won't show up until
something goes horribly wrong and the program calls
process_single_widget() anyway.

Personally, I think the best solution is to make sure your code
is written and reviewed by people who know the difference
between "=" and "==". (Yeah, that's glib; I'd also require
programmers to pay attention to warnings.)

Actually, the *best* solution is to hop into a time machine and
tell Dennis Ritchie to use "=" for equality and ":=" for
assignment, or something similarly distinctive. It's a pity
that time machines invoke undefined behavior (real demons, real
noses).

A syntax that doesn't look like an equation would be even harder
to screw up.

store(x, 12);

Oh really? What does:

store (a,b);

mean to anyone? Store the contents of a into b or the other way
around?

Oz

[Ashish]

<ro********@tesco.net> wrote in message
news:bd**************************@posting.google.c om...

"Ashish" <as*****@hotmail.com> wrote in message news:<bl************@ID-75446.news.uni-berlin.de>...

"Vijay Kumar R Zanvar" <vi*****@hotmail.com> wrote in message
news:bl************@ID-203837.news.uni-berlin.de...

<snip>

Tip:

The compiler may only produce a waring: "Possibly incorrect
assignment", but we may ignore it. To avoid such a mistake,
just reverse the two identifiers.

if ( 2 == i )
{
/* do something */
}

If '==' is replaced by an '=', the compiler will give an error
saying "Lvalue required".
<snip>

Are you still living in the 19th century? This has been discussed

millions of times.

"If I've told you once, I've told you a million times, avoid hyperbole."

Huh?
W.Saffire

[goose]

Neil Cerutti <ho*****@yahoo.com> wrote in message news:<bl************@ID-60390.news.uni-berlin.de>...

<snipped rest of = vs == argument>

A syntax that doesn't look like an equation would be even harder
to screw up.

store(x, 12);

even better, use memcmp() for all equality comparisons
of integers, and have all magic numbers as constant variables.

goose,
more typing, less haste ... or somethinglike that

[Arthur J. O'Dwyer]

On Fri, 3 Oct 2003, Richard Heathfield wrote:

Arthur J. O'Dwyer wrote:

On Thu, 2 Oct 2003, Richard Heathfield wrote:

James Antill wrote:
>
> Well personally find...
>
> if (i == 1) {}
>
> ...much more readable/clear over...
>
> if (1 == i) {}

Do you find x == y clearer than y == x? If so, why? If not,
why do you find i == 1 clearer than 1 == i?

Obviously because one expresses the writer's intent more clearly.

Hmmm. If it's "obvious", how come I don't see it?

Don't ask _me_. :-)

It is a long-standing tradition at least in English-language
mathematical notation to put the variable on the left and the
value on the right, e.g.

It's a long-standing tradition, at least in English-language mathematical
notation, for:

i = i + 1

to have no real solutions. But programmers don't hesitate to discard that
baggage when it suits them.

Not really. The = sign in mathematics just means something slightly
different than it does in C. If you want Pascal or BASIC, you know
where to find them. (The mathematical = relation is equivalent to the
C == operator, and indeed in C (i == i+1) has no solution for
unsigned integral i.)

Possibly also a factor is
the English grammatical pattern

"_He_ is Bob." answers the question "Who is _he_?"

This isn't the same concept as "is /this/ scalar value the same as /that/
scalar value?".

Sure, it is. Except for the use of names and people instead of variables
and values, of course. And of course I'm not arguing for any particular
ordering of different variable names or values; (x==y) and (y==x) behave
exactly the same, out of context. I'm merely pointing out that (x==1)
and (1==x) -- variable-to-value comparisons -- have different semantic
content.

"_X_ equals 1." answers the question "What is _X_?"

It is just as valid IMHO to say that it answers the question "is the value
of _X_ equal to 1?"

True.

"1 equals _X_." seems to answer the question "What is 1?",

See above

....where, by analogy, we have "is the value of 1 equal to _X_?" That's
just as silly; you've just added more words to the question.

which is intuitively perceived as silly, since everyone (except
maybe a few experts ;-)

<g>

already knows what 1 is -- it's 1!

But does it have the same value as X? I think we should be told.

In the mathematical sense, who cares? We already _know_ what 1 is,
and what it means. We're usually interested in solving for _X_;
finding out what _X_ is.

I don't know of any languages that do the he-is-bob pattern
differently, so I'm confident that it's fairly universal.

I don't know of any conforming C compilers that don't issue a diagnostic for
if(1 = x), so I'm confident that it's fairly universal.

ITYM you're confident that the construct is *not* universal,
but the [required] diagnostic is. I think you're right.

-Arthur

[Neil Cerutti]

In article <3f7d742d.1372277500@news-server>, ozbear wrote:

A syntax that doesn't look like an equation would be even
harder to screw up.

store(x, 12);

Oh really? What does:

store (a,b);

mean to anyone? Store the contents of a into b or the other
way around?

It would mean one and never the other.

--
Neil Cerutti

[Neil Cerutti]

In article <ff**************************@posting.google.com >,
goose wrote:

Neil Cerutti <ho*****@yahoo.com> wrote in message
news:<bl************@ID-60390.news.uni-berlin.de>...

<snipped rest of = vs == argument>

A syntax that doesn't look like an equation would be even
harder to screw up.

store(x, 12);

even better, use memcmp() for all equality comparisons of
integers, and have all magic numbers as constant variables.

Heh.

In C99, you can even write your own store: an inline function.

--
Neil Cerutti

[Richard Heathfield]

Jeremy Yallop wrote:

Richard Heathfield wrote:

<shrug> C is not English. In this case, by the way, it would be a rather
more accurate comparison if you were to write: "if seventeen is
Geraldine's age" and "if Geraldine's age is seventeen".
I don't want to belabour the point,

Neither do I. Ultimately, it's a style thing, and no style argument ever got
settled here.
but the former still sounds
unnatural to me.
It does to me, too, in English. I tend to think of C and English as separate
languages, though. :-)

I think you'll find that the == operator denotes equality, not set
membership.

It denotes value equality, yes, but a variable is not the same /kind/
of thing as a literal, which is why most people do not find "if (x == 1)"
and "if (1 == x)" equally readable, whichever they prefer.

(Given that neither of us is going to persuade the other...) How do you feel
about these code fragments?

if(SUCCESS == rc)

if(Success == rc)

if(success == rc)

I'm just curious. I ***promise*** I won't argue with your reply (because
it's a style thing, so I'm taking it as read that we've agreed to differ).

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Arthur J. O'Dwyer]

On Fri, 3 Oct 2003, Richard Heathfield wrote:

Jeremy Yallop wrote:

Richard Heathfield wrote:

<shrug> C is not English. In this case, by the way, it would be a rather
more accurate comparison if you were to write: "if seventeen is
Geraldine's age" and "if Geraldine's age is seventeen".
I don't want to belabour the point,

Neither do I. Ultimately, it's a style thing, and no style argument ever got
settled here.

True dat.
So I'll try to avoid this thread, but since I've been
belabo[u]ring the point, too, here's some feedback on
the below.
(Given that neither of us is going to persuade the other...) How
do you feel about these code fragments?
First off, all of them should have whitespace between the keyword
'if' and the open parenthesis '('. 'if', like 'sizeof' and 'return',
is not a function. :-)
if(SUCCESS == rc)
Looks like SUCCESS is a macro. Which has a constant value.
So 'rc' must be a variable, probably a return code. So this
comparison means "if the return code is SUCCESS, do x."
It's backwards [:-)], but readable at a glance.
if(Success == rc)
Hmm. I don't write code that looks like that. My first
impression would be that 'Success' is a global variable,
or more likely a member of an enumeration. But I'd have
to check to make sure, and I'd look first at the top of
the current source file.
if(success == rc)
Ambiguous out of context. 'success' is a plausible name
for a boolean variable (or an 'int' masquerading as a
boolean). It's only by looking above and below this line
that I can tell that 'rc', being briefer, must be the
variable name, and 'success', being non-orthogonal to
'rc' (i.e., not named 'sc' or 'rd' or something similar)
must really be a constant.

Perhaps I'd write this in the dubious context
rc = vsscanf(input_buffer, user_defined_fmt, ap);
success = user_defined_number_of_values + 1;
if (success == rc)
...

but again, I'd be more likely to think, "Is RC successful?"
than "Is 'success' equal to RC?" and thus write the condition
the other way.

I'm just curious. I ***promise*** I won't argue with your reply (because
it's a style thing, so I'm taking it as read that we've agreed to differ).

-Arthur

[robin.pain]

"Ashish" <as*****@hotmail.com> wrote in message news:<bl************@ID-75446.news.uni-berlin.de>...

<ro********@tesco.net> wrote in message
news:bd**************************@posting.google.c om...

"Ashish" <as*****@hotmail.com> wrote in message

news:<bl************@ID-75446.news.uni-berlin.de>...

"Vijay Kumar R Zanvar" <vi*****@hotmail.com> wrote in message
news:bl************@ID-203837.news.uni-berlin.de...

<snip>

> Tip:
>
> The compiler may only produce a waring: "Possibly incorrect
> assignment", but we may ignore it. To avoid such a mistake,
> just reverse the two identifiers.
>
> if ( 2 == i )
> {
> /* do something */
> }
>
> If '==' is replaced by an '=', the compiler will give an error
> saying "Lvalue required".

<snip>

Are you still living in the 19th century? This has been discussed millions of times.

"If I've told you once, I've told you a million times, avoid hyperbole."

Huh?

W.Saffire

It's an exaggerated version of W. Saffire's "fumble rule" No 6:-

http://www.utexas.edu/coc/journalism/SOURCE/student_org/!hints2.htm

Robin

[CBFalconer]

"Arthur J. O'Dwyer" wrote:

On Fri, 3 Oct 2003, Richard Heathfield wrote:

.... snip ...

(Given that neither of us is going to persuade the other...)
How do you feel about these code fragments?

First off, all of them should have whitespace between the keyword
'if' and the open parenthesis '('. 'if', like 'sizeof' and
'return', is not a function. :-)

New style war. You are not going to persuade him, I have tried
:-)

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Richard Heathfield]

Arthur J. O'Dwyer wrote:

On Fri, 3 Oct 2003, Richard Heathfield wrote:

(Given that neither of us is going to persuade the other...) How
do you feel about these code fragments?

First off, all of them should have whitespace between the keyword
'if' and the open parenthesis '('. 'if', like 'sizeof' and 'return',
is not a function. :-)

You're not Jeremy, so I haven't promised not to argue with you. :-)

Seriously, whitespace is /also/ a style issue. In your eyes, the additional
whitespace between if and ( is desirable. In my eyes, it isn't. So - FOR
YOU - it /should/ be there (or, perhaps, /must/ be there?). For me, it must
not.

<very interesting comments snipped - I will *not* get deeply involved in a
style discussion; I will *not* get deeply involved in a style discussion; I
will *not* get deeply involved in a style discussion; I will *not* get
deeply involved in a style discussion; I will *not* get deeply involved in
a style discussion; I will *not* get deeply involved in a style discussion;
I will *not* get deeply involved in a style discussion...>

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Joona I Palaste]

Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> scribbled the following:

On Fri, 3 Oct 2003, Richard Heathfield wrote:

It's a long-standing tradition, at least in English-language mathematical
notation, for:

i = i + 1

to have no real solutions. But programmers don't hesitate to discard that
baggage when it suits them.

Not really. The = sign in mathematics just means something slightly
different than it does in C. If you want Pascal or BASIC, you know
where to find them. (The mathematical = relation is equivalent to the
C == operator, and indeed in C (i == i+1) has no solution for
unsigned integral i.)

Invalid point. BASIC uses = for *both* assignment and equality. The
difference is whether it's used in a (possibly implicit) LET command or
in an expression.
Pascal, OTOH, is free of such confusion and uses := for assignment.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"The question of copying music from the Internet is like a two-barreled sword."
- Finnish rap artist Ezkimo