(0 == foo), rather than (foo == 0)

(0 == foo), rather than (foo == 0)

[Godbole, Amarendra (GE Consumer & Industrial)]

Hi,

While writing code, the assignment operator (=) is many-a-times confused with the comparison operator (==) resulting in very subtle bugs difficult to track. To keep a check on this -- the constant can be written on the LHS rather than the RHS which will result in a compile time error if wrong operator is used.

Is this an encouraged practice while writing any code for the kernel ? Or is this choice left to the developer ? I was unable to find any reference to it in the CodingStyle document. I did find some code under drivers/ which used (NULL == foo) and similar constructs. 

Can this be added to the CodingStyle document ?

Cheers,
Amarendra

--
#include <std$disclaimer.h>

Re: (0 == foo), rather than (foo == 0)

[Bernd Petrovitsch]

Reformatted long lines - please fix your mailer.

On Mit, 2004-03-10 at 07:16, Godbole, Amarendra (GE Consumer &
Industrial) wrote:
> While writing code, the assignment operator (=) is many-a-times confused
> with the comparison operator (==) resulting in very subtle bugs difficult
> to track. To keep a check on this -- the constant can be written on the 
> LHS rather than the RHS which will result in a compile time error if wrong
> operator is used.

Or you use `gcc -Wall` which also reports this (and also in the cases
where both sides of the comparison can be left hand sides).

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: (0 == foo), rather than (foo == 0)

[Randy.Dunlap]

On Wed, 10 Mar 2004 11:46:40 +0530 Godbole, Amarendra \(GE Consumer & Industrial\) wrote:

| Hi,
| 
| While writing code, the assignment operator (=) is many-a-times confused with the comparison operator (==) resulting in very subtle bugs difficult to track. To keep a check on this -- the constant can be written on the LHS rather than the RHS which will result in a compile time error if wrong operator is used.

Yes, we know.

| Is this an encouraged practice while writing any code for the kernel ? Or is this choice left to the developer ? I was unable to find any reference to it in the CodingStyle document. I did find some code under drivers/ which used (NULL == foo) and similar constructs. 

I prefer that it be left to each developer.

| Can this be added to the CodingStyle document ?

Hopefully not.  Some of us think that it's ugly.

BTW, can you use CR/LF every 70 characters or so, please?

--
~Randy

Re: (0 == foo), rather than (foo == 0)

[Richard B. Johnson]

On Wed, 10 Mar 2004, Randy.Dunlap wrote:

> On Wed, 10 Mar 2004 11:46:40 +0530 Godbole, Amarendra \(GE Consumer &
> Industrial\) wrote:
>
> Hi,
>
> While writing code, the assignment operator (=) is many-a-times
> confused with the comparison operator (==) resulting in very subtle
> bugs difficult to track. To keep a check on this -- the constant
> can be written on the LHS rather than the RHS which will result
> in a compile time error if wrong operator is used.
>

People who develop kernel code know the difference between
'==' and '=' and are never confused my them. If you make
contributions to kernel code, and write: "if (0==foo)", your
code will be reviewed until it is obsolete and never find
its way into the kernel. Please don't insult kernel developers
with this kind of kid-stuff.

People who develop kernel code also know what a line-warp is.
They put a '\n' "[Enter] key" in their text every so-often,
maybe every 70 to 79 characters...

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

[OT] Re: (0 == foo), rather than (foo == 0)

[David Ford]

Richard B. Johnson wrote:

>People who develop kernel code also know what a line-warp is.
>They put a '\n' "[Enter] key" in their text every so-often,
>maybe every 70 to 79 characters...
>  
>

*thinks back to that 40
character screen wrap
that everyone used to
hound everyone else
for*

Really, your mail reading software should be capable of wrapping things 
by itself, we really have progressed from yesteryear.

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[Roland Dreier]

    David> Really, your mail reading software should be capable of
    David> wrapping things by itself, we really have progressed from
    David> yesteryear.

The problem is that if (say) you use 100 character lines, then someone
reading it in an 80-column window sees 80-char line, 20-char line, etc
etc and it's very annoying to read.  If you make every paragraph one
huge line, then when someone wants to quote your message, they have to
wrap the quote themselves.

Keeping email lines to about 70 characters is still the best policy.

 - Roland

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[David Ford]

No, the problem is your mail reader or configuration is broken.  Both 
Pine and Mutt both wrap lines just fine, and all the GUI interface I've 
used (in recent years) wrap just fine.  a) they aren't recognizing soft 
line breaks or b) you're not acknowledging lines sent without any wraps.

Letting users wrap text where they want to is the best policy.

Roland Dreier wrote:

>    David> Really, your mail reading software should be capable of
>    David> wrapping things by itself, we really have progressed from
>    David> yesteryear.
>
>The problem is that if (say) you use 100 character lines, then someone
>reading it in an 80-column window sees 80-char line, 20-char line, etc
>etc and it's very annoying to read.  If you make every paragraph one
>huge line, then when someone wants to quote your message, they have to
>wrap the quote themselves.
>
>Keeping email lines to about 70 characters is still the best policy.
>
> - Roland
>  
>

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[Roland Dreier]

    David> No, the problem is your mail reader or configuration is
    David> broken.  Both Pine and Mutt both wrap lines just fine, and
    David> all the GUI interface I've used (in recent years) wrap just
    David> fine.  a) they aren't recognizing soft line breaks or b)
    David> you're not acknowledging lines sent without any wraps.

How do these mail readers wrap quotes like the above?

 - R.

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[Måns Rullgård]

Roland Dreier <roland@topspin.com> writes:

>     David> No, the problem is your mail reader or configuration is
>     David> broken.  Both Pine and Mutt both wrap lines just fine,
>     David> and all the GUI interface I've used (in recent years)
>     David> wrap just fine.  a) they aren't recognizing soft line
>     David> breaks or b) you're not acknowledging lines sent without
>     David> any wraps.
>
> How do these mail readers wrap quotes like the above?

Don't know about those, but gnus does a good job.  BTW, quotes should
use the string "> " at column 0, nothing else.

-- 
Måns Rullgård
mru@kth.se

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[Bill Davidsen]

Måns Rullgård wrote:
> Roland Dreier <roland@topspin.com> writes:
> 
> 
>>    David> No, the problem is your mail reader or configuration is
>>    David> broken.  Both Pine and Mutt both wrap lines just fine,
>>    David> and all the GUI interface I've used (in recent years)
>>    David> wrap just fine.  a) they aren't recognizing soft line
>>    David> breaks or b) you're not acknowledging lines sent without
>>    David> any wraps.
>>
>>How do these mail readers wrap quotes like the above?
> 
> 
> Don't know about those, but gnus does a good job.  BTW, quotes should
> use the string "> " at column 0, nothing else.

Feel free to do that. After about 3-4 levels of quote replacing ">>>>" 
with a name makes it more readable. I'm not suggesting making that a 
standard, but I certainly won't complain about someone making my life 
easier, either.
-- 
		-bill

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[Richard B. Johnson]

On Wed, 10 Mar 2004, David Ford wrote:

> Richard B. Johnson wrote:
>
> >People who develop kernel code also know what a line-warp is.
> >They put a '\n' "[Enter] key" in their text every so-often,
> >maybe every 70 to 79 characters...
> >
> >
>
> *thinks back to that 40
> character screen wrap
> that everyone used to
> hound everyone else
> for*
>
> Really, your mail reading software should be capable of wrapping things
> by itself, we really have progressed from yesteryear.
>

No. You can set your screen size to anything. If you have a very
high resolution screen, perhaps even 400 columns. If you are
sending mail to somebody, you need to make sure it fits on
their page, not your page.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[David Ford]

Richard B. Johnson wrote:

>On Wed, 10 Mar 2004, David Ford wrote:
>  
>
>[...]
>  
>

>No. You can set your screen size to anything. If you have a very
>high resolution screen, perhaps even 400 columns. If you are
>sending mail to somebody, you need to make sure it fits on
>their page, not your page.
>  
>

And you have no idea what size screen they have.  Some text users I know 
like to keep their screens at 60 chars so they can fit more terms on 
their desktop.  Others have 100+ columns.  Let the end user flow the 
text according to their own wishes.

Basic concept in good content presentation, you provide the content and 
style, let the reader render it according to their page 
characteristics.  Don't try to force everyone into 640x480, 72 columns, 
or a particular text size.

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[Frank v Waveren]

On Wed, Mar 10, 2004 at 02:31:15PM -0500, David Ford wrote:
> >high resolution screen, perhaps even 400 columns. If you are
> >sending mail to somebody, you need to make sure it fits on
> >their page, not your page.
> And you have no idea what size screen they have.  Some text users I know 
> like to keep their screens at 60 chars so they can fit more terms on 
> their desktop.  Others have 100+ columns.  Let the end user flow the 
> text according to their own wishes.
> 
> Basic concept in good content presentation, you provide the content and 
> style, let the reader render it according to their page 
> characteristics.  Don't try to force everyone into 640x480, 72 columns, 
> or a particular text size.

This is good design, however horribly incompatible with the current
state of email/news postings. Luckily, a solution that doesn't break
anything has been found: If you want your text wrapped by the MUA, use
format=flowed in the content type header. Read RFC 2646.

-- 
Frank v Waveren                                      Fingerprint: 9106 FD0D
fvw@[var.cx|stack.nl|dse.nl] ICQ#10074100               D6D9 3E7D FAF0 92D1
Public key: hkp://wwwkeys.pgp.net/8D54EB90              3931 90D6 8D54 EB90

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[Måns Rullgård]

Frank v Waveren <fvw@var.cx> writes:

> This is good design, however horribly incompatible with the current
> state of email/news postings. Luckily, a solution that doesn't break
> anything has been found: If you want your text wrapped by the MUA, use
> format=flowed in the content type header. Read RFC 2646.

But don't do that if there's C (or other) code in the message.

-- 
Måns Rullgård
mru@kth.se

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[David Ford]

Look at the headers of my emails.  The content type is format=flowed.

Frank v Waveren wrote:

>This is good design, however horribly incompatible with the current
>state of email/news postings. Luckily, a solution that doesn't break
>anything has been found: If you want your text wrapped by the MUA, use
>format=flowed in the content type header. Read RFC 2646.
>  
>

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On Thu, 11 Mar 2004 00:20:18 +0100, Frank v Waveren said:

> This is good design, however horribly incompatible with the current
> state of email/news postings. Luckily, a solution that doesn't break
> anything has been found: If you want your text wrapped by the MUA, use
> format=flowed in the content type header. Read RFC 2646.

Unfortunately, the most offending MUA in this regard likes to generate text
that would benefit from format=flowed, but fails to actually specify it in the
appropriate MIME markup.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[Peter Williams]

Richard B. Johnson wrote:
> On Wed, 10 Mar 2004, David Ford wrote:
> 
> 
>>Richard B. Johnson wrote:
>>
>>
>>>People who develop kernel code also know what a line-warp is.
>>>They put a '\n' "[Enter] key" in their text every so-often,
>>>maybe every 70 to 79 characters...
>>>
>>>
>>
>>*thinks back to that 40
>>character screen wrap
>>that everyone used to
>>hound everyone else
>>for*
>>
>>Really, your mail reading software should be capable of wrapping things
>>by itself, we really have progressed from yesteryear.
>>
> 
> 
> No. You can set your screen size to anything. If you have a very
> high resolution screen, perhaps even 400 columns. If you are
> sending mail to somebody, you need to make sure it fits on
> their page, not your page.

My mail program (netscape) (when so configured) automatically wraps 
lines (at a specified width - I use 72) for me by inserting new line 
characters when it sends the message.  It also wraps lines while I'm 
editing but without the new line characters so that when I delete some 
characters or insert some new ones in the middle of a paragraph I don't 
have to reformat the paragraph. I like this feature and assume that any 
reasonably modern mail program provides the same feature.  So what's all 
the fuss about?

Peter
-- 
Dr Peter Williams, Chief Scientist                peterw@aurema.com
Aurema Pty Limited                                Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia  Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[viro]

n Wed, Mar 10, 2004 at 01:50:29PM -0500, David Ford wrote:
> 
> *thinks back to that 40
> character screen wrap
> that everyone used to
> hound everyone else
> for*
> 
> Really, your mail reading software should be capable of wrapping things 
> by itself, we really have progressed from yesteryear.

Kindly piss off.  My mail reading software uses vi(1) to compose the
reply and has enough sense to preserve the line boundaries.

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[David Ford]

I won't.  I didn't say anything against inability to preserve line 
boundaries.  I was, and am, referring to linear text and letting the end 
user reflow that text to suit his or her preferences.

viro@parcelfarce.linux.theplanet.co.uk wrote:

>Kindly piss off.  My mail reading software uses vi(1) to compose the
>reply and has enough sense to preserve the line boundaries.
>  
>

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[Richard B. Johnson]

On Wed, 10 Mar 2004, David Ford wrote:

> I won't.  I didn't say anything against inability to preserve line
> boundaries.  I was, and am, referring to linear text and letting the end
> user reflow that text to suit his or her preferences.
>

Hmmm. What is linear text? Is it okay to auto-wrap i
n
t
he
mid
dle of text, not on white-space boundaries, like it
does when somebody just streams out a bunch of bytes?

> viro@parcelfarce.linux.theplanet.co.uk wrote:
>
> >Kindly piss off.  My mail reading software uses vi(1) to compose the
> >reply and has enough sense to preserve the line boundaries.
> >
> >
>

The pine mailer that I use, uses pico as its editor. When I attempt
to write a response that has previous quotes, the stuff that doesn't
fit on a line just piles up at the end of the window. It gets replaced
by a '$' so you know that there is more text. `vi` isn't so kind.
You don't know what's hidden unless you put a new-line in at the
end or want to space to the right up to 4094 bytes (it allows lines
to be that long, last I checked). With vi, you get a line of text like thi

You don't know what's beyond the 'i' of "thi", above. It might
be several hundred important words so you need to space the cursor
over there and look beyond the screen boundaries.

When you want text to be read by others, you make sure they
can read it. It's just that simple. There are some assumptions
that you can make. You can assume that they have a way of
reading 80-column text, for instance.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[Micha Feigin]

On Wed, Mar 10, 2004 at 05:42:20PM -0500, Richard B. Johnson wrote:
[ ... snip ... ]
> 
> When you want text to be read by others, you make sure they
> can read it. It's just that simple. There are some assumptions
> that you can make. You can assume that they have a way of
> reading 80-column text, for instance.
> 

actually 72 is usually better since it leaves some room for the > of
the replies to pile up a bit without passing the 80 column boundary.

> 
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
>             Note 96.31% of all statistics are fiction.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[Giuseppe Bilotta]

Micha Feigin wrote:
> On Wed, Mar 10, 2004 at 05:42:20PM -0500, Richard B. Johnson wrote:
> [ ... snip ... ]
> > 
> > When you want text to be read by others, you make sure they
> > can read it. It's just that simple. There are some assumptions
> > that you can make. You can assume that they have a way of
> > reading 80-column text, for instance.
> > 
> 
> actually 72 is usually better since it leaves some room for the > of
> the replies to pile up a bit without passing the 80 column boundary.

Nitpick by nitpick, it should be kept at 66 since lines longer than 
66 characters become very stressfull on the eyes.


-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[Stefan Smietanowski]

David Ford wrote:

> I won't.  I didn't say anything against inability to preserve line 
> boundaries.  I was, and am, referring to linear text and letting the end 
> user reflow that text to suit his or her preferences.
> 
> viro@parcelfarce.linux.theplanet.co.uk wrote:
> 
>> Kindly piss off.  My mail reading software uses vi(1) to compose the
>> reply and has enough sense to preserve the line boundaries.

You also don't have a clue what replying below is all about nor do you
respond to anything regarding quotes. How many times haven't we seen
stupid quotes like this :

 > blah blah long long line ..........................
end of last line > here is the second line that's quoted
end of second line......... > and here starts the third one.

If you haven't - lucky you. But don't try to push your
reply-above-and-don't-give-a-piss-about-others approach.

This list replies below and uses manually wrapped lines.

If you want to create your own linux kernel list with other
rules - be free to do so, but if you want to continue talking
on this one, follow the rules on it, don't try to push your own.

// Stefan

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[David Ford]

Why don't you read the whole thread.  I'm not pushing any rules, and 
I've been replying "to the top" of emails on LKML for almost ten years.  
If your mailer wraps lines wrongly, that's the fault of your mailer.  I 
haven't had problems with mixed up quoting.  Not all software is created 
inferior..  I don't have to reply if someone else has already stated 
what needed to be said.  If you don't like my quote-above-reply, then 
filter my emails.

David
p.s. If you want to follow the 'rules' of RFC 1855, then there are 
several this list is 'breaking', this RFC is informational, a guide.  
Not law.  Your message violates RFC 1855.

Stefan Smietanowski wrote:

> You also don't have a clue what replying below is all about nor do you
> respond to anything regarding quotes. How many times haven't we seen
> stupid quotes like this :
>
> > blah blah long long line ..........................
> end of last line > here is the second line that's quoted
> end of second line......... > and here starts the third one.
>
> If you haven't - lucky you. But don't try to push your
> reply-above-and-don't-give-a-piss-about-others approach.
>
> This list replies below and uses manually wrapped lines.
>
> If you want to create your own linux kernel list with other
> rules - be free to do so, but if you want to continue talking
> on this one, follow the rules on it, don't try to push your own.
>
> // Stefan

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[Måns Rullgård]

David Ford <david+challenge-response@blue-labs.org> writes:

> I've been replying "to the top" of emails on LKML for almost ten
> years.

Then it's about time you stopped.

Fortunately, my mailer (gnus) knows how to fix most forms of
top-posting, even the abhorrent msoutlook variant.

-- 
Måns Rullgård
mru@kth.se

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[Stefan Smietanowski]

Hi.

> Why don't you read the whole thread.  I'm not pushing any rules, and 

I have and didn't reply before but I did now.

> I've been replying "to the top" of emails on LKML for almost ten years.  

Think about changing perhaps.

> If your mailer wraps lines wrongly, that's the fault of your mailer.  I 
> haven't had problems with mixed up quoting.  Not all software is created 
> inferior..  I don't have to reply if someone else has already stated 

If my mailer wraps it wrong I might consider it the fault of my mailer.
It doesn't however, but that's beside the point. Messed up quoting
due to long lines is common and there are no rules that you must use
perfect mailers.

> what needed to be said.  If you don't like my quote-above-reply, then 
> filter my emails.

I thought of that actually ...

> David
> p.s. If you want to follow the 'rules' of RFC 1855, then there are 
> several this list is 'breaking', this RFC is informational, a guide.  
> Not law.  Your message violates RFC 1855.

As you said, RFC 1855 is informational and this list has it's own
set of rules. And no, RFC 1855 is not the same as the list rules
as you point out.

Nobody has ever bothered writing an RFC about lkml :)

// Stefan

Re: [OT] Re: (0 == foo), rather than (foo == 0)

[Matthew Garrett]

David Ford wrote:

>Really, your mail reading software should be capable of wrapping things 
>by itself, we really have progressed from yesteryear.

The issue is that there are two types of text. The message itself should
be wrapped, whereas inline code may be semantically changed by being
wrapped. If both are streams of text with no embedded newlines then
there's no way of telling the difference between them, whereas if one
has embedded newlines then the choice of wrapping the other can be made
by the recipient. The alternative would result in both being wrapped,
which isn't the behaviour I want. Having lines that are slightly shorter
than ideal on some people's screens seems the lesser of two evils.

-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org

Re: (0 == foo), rather than (foo == 0)

[Peter Williams]

Richard B. Johnson wrote:
> On Wed, 10 Mar 2004, Randy.Dunlap wrote:
> 
> 
>>On Wed, 10 Mar 2004 11:46:40 +0530 Godbole, Amarendra \(GE Consumer &
>>Industrial\) wrote:
>>
>>Hi,
>>
>>While writing code, the assignment operator (=) is many-a-times
>>confused with the comparison operator (==) resulting in very subtle
>>bugs difficult to track. To keep a check on this -- the constant
>>can be written on the LHS rather than the RHS which will result
>>in a compile time error if wrong operator is used.
>>
> 
> 
> People who develop kernel code know the difference between
> '==' and '=' and are never confused my them.

And you never make typing mistakes?  That's admirable or should I say 
incredible.

> If you make
> contributions to kernel code, and write: "if (0==foo)", your
> code will be reviewed until it is obsolete and never find
> its way into the kernel. Please don't insult kernel developers
> with this kind of kid-stuff.
> 
> People who develop kernel code also know what a line-warp is.
> They put a '\n' "[Enter] key" in their text every so-often,
> maybe every 70 to 79 characters...
> 
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
>             Note 96.31% of all statistics are fiction.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


-- 
Dr Peter Williams, Chief Scientist                peterw@aurema.com
Aurema Pty Limited                                Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia  Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com

Re: (0 == foo), rather than (foo == 0)

[Randy.Dunlap]

On Thu, 11 Mar 2004 10:00:56 +1100 Peter Williams wrote:

| Richard B. Johnson wrote:
| > On Wed, 10 Mar 2004, Randy.Dunlap wrote:
| > 
| > 
| >>On Wed, 10 Mar 2004 11:46:40 +0530 Godbole, Amarendra \(GE Consumer &
| >>Industrial\) wrote:
| >>
| >>Hi,
| >>
| >>While writing code, the assignment operator (=) is many-a-times
| >>confused with the comparison operator (==) resulting in very subtle
| >>bugs difficult to track. To keep a check on this -- the constant
| >>can be written on the LHS rather than the RHS which will result
| >>in a compile time error if wrong operator is used.
| >>
| > 
| > 
| > People who develop kernel code know the difference between
| > '==' and '=' and are never confused my them.
| 
| And you never make typing mistakes?  That's admirable or should I say 
| incredible.

Whoa.  stop the presses.  an on-$subejct posting.

Please, let's kill all the other fuss about email crapola...

--
~Randy

Re: (0 == foo), rather than (foo == 0)

[Linus Torvalds]

On Thu, 11 Mar 2004, Peter Williams wrote:
> Richard B. Johnson wrote:
> > 
> > People who develop kernel code know the difference between
> > '==' and '=' and are never confused my them.
> 
> And you never make typing mistakes?  That's admirable or should I say 
> incredible.

The thing is, people tend to make fewer typing mistakes of that kind, than 
just plain logic errors from not thinking right about something.

And while "0 == foo" may be logically the same thing as "foo == 0", the 
fact is, the latter is what people are used to seeing. And by being used 
to seeing it, they have an easier time thinking about it.

As a result, using the former just tends to increase peoples confusion by
making code harder to read, which in turn tends to increase the chance of 
bugs.

So don't do it. The kind of bug that the "0 == x" syntax protects against
is LESS LIKELY to happen than the kind of bug it tends to cause.

		Linus

Re: (0 == foo), rather than (foo == 0)

[Peter Williams]

Linus Torvalds wrote:
> 
> On Thu, 11 Mar 2004, Peter Williams wrote:
> 
>>Richard B. Johnson wrote:
>>
>>>People who develop kernel code know the difference between
>>>'==' and '=' and are never confused my them.
>>
>>And you never make typing mistakes?  That's admirable or should I say 
>>incredible.
> 
> 
> The thing is, people tend to make fewer typing mistakes of that kind, than 
> just plain logic errors from not thinking right about something.
> 
> And while "0 == foo" may be logically the same thing as "foo == 0", the 
> fact is, the latter is what people are used to seeing. And by being used 
> to seeing it, they have an easier time thinking about it.
> 
> As a result, using the former just tends to increase peoples confusion by
> making code harder to read, which in turn tends to increase the chance of 
> bugs.
> 
> So don't do it. The kind of bug that the "0 == x" syntax protects against
> is LESS LIKELY to happen than the kind of bug it tends to cause.
> 
> 		Linus

OK.  I'll change all of such occurences in our EBS patches.

As somebody pointed out -Wall will (help) detect most of these errors by 
suggesting () be placed around any expression of the form a = b that 
occurs inside a simple boolean expression which will cause those people 
who care about eliminating warning messages to reevaluate the code and 
make sure they really meant a = b and replace it with (a = b) to get rid 
of the warning error.

The reason that I say "most" rather than "all" is (that testing shows) 
that if the a = b is part of a more complex expression and is already in 
() in order to (for instance) ensure the desired precedence -Wall will 
not flag it as a possible problem.

Peter
-- 
Dr Peter Williams, Chief Scientist                peterw@aurema.com
Aurema Pty Limited                                Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia  Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com

Re: (0 == foo), rather than (foo == 0)

[Linus Torvalds]

On Thu, 11 Mar 2004, Peter Williams wrote:
> 
> As somebody pointed out -Wall will (help) detect most of these errors by 
> suggesting () be placed around any expression of the form a = b that 
> occurs inside a simple boolean expression which will cause those people 
> who care about eliminating warning messages to reevaluate the code and 
> make sure they really meant a = b and replace it with (a = b) to get rid 
> of the warning error.

Actually, don't just add parenthesis. They get rid of the warning, but 
they don't actually make for very pretty reading.

I don't know why the gcc warning suggests adding parentheses, since they 
have no semantic meaning, and are _horrible_ from a syntactic standpoint.

The warning should be there whether there are parenthesis or not, and it 
should state that you should have an explicit inequality expression. So if 
you have

	if (a = b) 
		...

and you really _mean_ that, then the way to write it sanely is to just 
write it as

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

which makes it much clearer what you're actually doing.

		Linus

Re: (0 == foo), rather than (foo == 0)

[Stefan Smietanowski]

Hi Linus.

> The warning should be there whether there are parenthesis or not, and it 
> should state that you should have an explicit inequality expression. So if 
> you have
> 
> 	if (a = b) 
> 		...
> 
> and you really _mean_ that, then the way to write it sanely is to just 
> write it as
> 
> 	if ((a = b) != 0)
> 		...
> 
> which makes it much clearer what you're actually doing.

Or actually change it to

a = b;
if (a)
   ...

That's even more clear in my opinion. The other still feels a bit iffy
but maybe that's just me.

// Stefan

Re: (0 == foo), rather than (foo == 0)

[Måns Rullgård]

Stefan Smietanowski <stesmi@stesmi.com> writes:

> Hi Linus.
>
>> The warning should be there whether there are parenthesis or not,
>> and it should state that you should have an explicit inequality
>> expression. So if you have
>> 	if (a = b) 		...
>> and you really _mean_ that, then the way to write it sanely is to
>> just write it as
>> 	if ((a = b) != 0)
>> 		...
>> which makes it much clearer what you're actually doing.
>
> Or actually change it to
>
> a = b;
> if (a)

That doesn't work with while().

-- 
Måns Rullgård
mru@kth.se

Re: (0 == foo), rather than (foo == 0)

[Stefan Smietanowski]

Hi Måns.

>>>The warning should be there whether there are parenthesis or not,
>>>and it should state that you should have an explicit inequality
>>>expression. So if you have
>>>	if (a = b) 		...
>>>and you really _mean_ that, then the way to write it sanely is to
>>>just write it as
>>>	if ((a = b) != 0)
>>>		...
>>>which makes it much clearer what you're actually doing.
>>
>>Or actually change it to
>>
>>a = b;
>>if (a)
> 
> That doesn't work with while().
> 

True. Didn't think of that but then the example used
was an if().

// Stefan

Re: (0 == foo), rather than (foo == 0)

[Andreas Schwab]

mru@kth.se (Måns Rullgård) writes:

> Stefan Smietanowski <stesmi@stesmi.com> writes:
>
>> Hi Linus.
>>
>>> The warning should be there whether there are parenthesis or not,
>>> and it should state that you should have an explicit inequality
>>> expression. So if you have
>>> 	if (a = b) 		...
>>> and you really _mean_ that, then the way to write it sanely is to
>>> just write it as
>>> 	if ((a = b) != 0)
>>> 		...
>>> which makes it much clearer what you're actually doing.
>>
>> Or actually change it to
>>
>> a = b;
>> if (a)
>
> That doesn't work with while().

But this works:  while (a = b, a != 0).
(not that it is any better readable :-) ).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: (0 == foo), rather than (foo == 0)

[Stefan Smietanowski]

Hi Andreas.

>>>>The warning should be there whether there are parenthesis or not,
>>>>and it should state that you should have an explicit inequality
>>>>expression. So if you have
>>>>	if (a = b) 		...
>>>>and you really _mean_ that, then the way to write it sanely is to
>>>>just write it as
>>>>	if ((a = b) != 0)
>>>>		...
>>>>which makes it much clearer what you're actually doing.
>>>
>>>Or actually change it to
>>>
>>>a = b;
>>>if (a)
>>
>>That doesn't work with while().
> 
> 
> But this works:  while (a = b, a != 0).
> (not that it is any better readable :-) ).

My eyes! *Starts clawing them out*

// Stefan

Re: (0 == foo), rather than (foo == 0)

[Bill Davidsen]

Stefan Smietanowski wrote:

>> But this works:  while (a = b, a != 0).
>> (not that it is any better readable :-) ).
> 
> 
> My eyes! *Starts clawing them out*

All in what you are used to reading. I grew up with ranges sepcified as 
something like
   0 <= x <= 40
in the spec, and therefore still write it like
   if (0 <= x && x <= 40)
because that makes it obvious (to me) that it's a range check.

A case of the language not having a range check operator and various 
people finding one thing or another readable.

-- 
		-bill

Re: (0 == foo), rather than (foo == 0)

[Willy Tarreau]

Hi,

On Wed, Mar 10, 2004 at 06:36:22PM -0800, Linus Torvalds wrote:
> 
> And while "0 == foo" may be logically the same thing as "foo == 0", the 
> fact is, the latter is what people are used to seeing. And by being used 
> to seeing it, they have an easier time thinking about it.
> 
> As a result, using the former just tends to increase peoples confusion by
> making code harder to read, which in turn tends to increase the chance of 
> bugs.

I have a friend who constantly uses it, and his code is unreadable, because
sometimes, a "0 == xxx" becomes "0 <= xxx" or "0 >= xxx" which is difficult
to understand. Thinking that xxx is negative because it's written on the
right side of a >= is complicated. And the worst he does is when he uses
functions : 

   if (0 < strcmp(a, "xxx")) ...
   if (sizeof(t) > read(fd, t, sizeof(t)) ...

I have already helped him track bugs in his programs, and some of them were
just related to this usage, because nobody's brain can understand these
constructions immediately without thinking a bit. So I'm all against this
sort of thing.

Cheers,
Willy

Re: (0 == foo), rather than (foo == 0)

[Peter Williams]

Willy Tarreau wrote:
> Hi,
> 
> On Wed, Mar 10, 2004 at 06:36:22PM -0800, Linus Torvalds wrote:
> 
>>And while "0 == foo" may be logically the same thing as "foo == 0", the 
>>fact is, the latter is what people are used to seeing. And by being used 
>>to seeing it, they have an easier time thinking about it.
>>
>>As a result, using the former just tends to increase peoples confusion by
>>making code harder to read, which in turn tends to increase the chance of 
>>bugs.
> 
> 
> I have a friend who constantly uses it, and his code is unreadable, because
> sometimes, a "0 == xxx" becomes "0 <= xxx" or "0 >= xxx" which is difficult
> to understand. Thinking that xxx is negative because it's written on the
> right side of a >= is complicated. And the worst he does is when he uses
> functions : 
> 
>    if (0 < strcmp(a, "xxx")) ...
>    if (sizeof(t) > read(fd, t, sizeof(t)) ...
> 
> I have already helped him track bugs in his programs, and some of them were
> just related to this usage, because nobody's brain can understand these
> constructions immediately without thinking a bit. So I'm all against this
> sort of thing.

One final note.  I agree with all the statements of how awkward and 
unnatural the back to front boolean expressions look but I had adopted 
this technique (for myself) as a means of overcoming design shortcomings 
in the C language.  I intend to keep doing it in my private code (as 
it's saved my bacon a number of times) but will conform to Linus's 
standards for any contributions/patches I submit for kernel code (just 
as I would conform for any other person's standards if I were to 
contribute to their work).  In the long run, consistency in a body of 
code greatly enhances its readability.

Peace?
Peter
-- 
Dr Peter Williams, Chief Scientist                peterw@aurema.com
Aurema Pty Limited                                Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia  Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com

Re: (0 == foo), rather than (foo == 0)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

On Wed, 10 Mar 2004 13:33:53 EST, "Richard B. Johnson" said:

> People who develop kernel code know the difference between
> '==' and '=' and are never confused my them. If you make

Remember a few months ago when a lot of very clever people looked at
a line of code that said 'if (yadda yadda && (uid = 0))' that had been
inserted into the CVS tree, and it took a while for some of the very clever
people to notice the equally clever hack?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: (0 == foo), rather than (foo == 0)

[Richard B. Johnson]

On Thu, 11 Mar 2004 Valdis.Kletnieks@vt.edu wrote:

> On Wed, 10 Mar 2004 13:33:53 EST, "Richard B. Johnson" said:
>
> > People who develop kernel code know the difference between
> > '==' and '=' and are never confused my them. If you make
>
> Remember a few months ago when a lot of very clever people looked at
> a line of code that said 'if (yadda yadda && (uid = 0))' that had been
> inserted into the CVS tree, and it took a while for some of the very clever
> people to notice the equally clever hack?
>

No, and if you bothered to look at any code in the kernel, you'd
note that uid and friends are always associated with some little
pointy thingys. So, it wouldn't have been coded anything like that,
anyway.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: (0 == foo), rather than (foo == 0)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

On Thu, 11 Mar 2004 10:22:49 EST, "Richard B. Johnson" said:

> No, and if you bothered to look at any code in the kernel, you'd
> note that uid and friends are always associated with some little
> pointy thingys. So, it wouldn't have been coded anything like that,
> anyway.

Fine. 

+       if ((options == (__WCLONE|__WALL)) && (current->uid = 0))

Happy???

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

RE: (0 == foo), rather than (foo == 0)

[Godbole, Amarendra (GE Consumer & Industrial)]

> As a result, using the former just tends to increase peoples 
> confusion by making code harder to read, which in turn tends 
> to increase the chance of bugs.

Kindly don't insult the kernel developers' with such statements. ;-)
They are smart enough to understand such constructs, which, I 
deduce from what someone said earlier in this thread. So no 
confusion  would prevail here...[take it in a lighter vein folks, I 
am kidding.]

> So don't do it. The kind of bug that the "0 == x" syntax 
> protects against is LESS LIKELY to happen than the kind of 
> bug it tends to cause.

Agreed and understood. Thanks.

Sincere apologies for my previous ``non-text wrapped'' post. This
won't happen henceforth.

Cheers,
Amarendra

--
Picture Perfect Engineering / These opinions are mine.

Re: (0 == foo), rather than (foo == 0)

[Chip Salzenberg]

Valdis.Kletnieks@vt.edu writes:
>+       if ((options == (__WCLONE|__WALL)) && (current->uid = 0))

I remember that.  I wasn't scanning changes, but when it was shown up
in the news stories, I wasn't visually fooled for even a second.  You
can't code in C for decades without picking up good = vs. == radar.
-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K

Re: (0 == foo), rather than (foo == 0)

[Chip Salzenberg]

Amarendra.Godbole@ge.com writes:
>> As a result, using the former just tends to increase peoples 
>> confusion by making code harder to read, which in turn tends 
>> to increase the chance of bugs.
>
>Kindly don't insult the kernel developers' with such statements. ;-)
>They are smart enough to understand such constructs [...]

It's not about intelligence!  It's about the nature of human visual
pattern-matching.  Reading a pattern is always easier when you've seen
it thousands of times before.

Henry Spencer's dictum about brace style seems particularly apropos:

8.  Thou shalt make thy program's purpose and structure clear to thy
    fellow man by using the One True Brace Style, even if thou likest
    it not, for thy creativity is better used in solving problems than
    in creating beautiful new impediments to understanding.

And that's what "0 == foo" is: an impediment to understanding.
-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K

Re: (0 == foo), rather than (foo == 0)

[Peter Williams]

Chip Salzenberg wrote:
> Amarendra.Godbole@ge.com writes:
> 
>>>As a result, using the former just tends to increase peoples 
>>>confusion by making code harder to read, which in turn tends 
>>>to increase the chance of bugs.
>>
>>Kindly don't insult the kernel developers' with such statements. ;-)
>>They are smart enough to understand such constructs [...]
> 
> 
> It's not about intelligence!  It's about the nature of human visual
> pattern-matching.  Reading a pattern is always easier when you've seen
> it thousands of times before.
> 
> Henry Spencer's dictum about brace style seems particularly apropos:
> 
> 8.  Thou shalt make thy program's purpose and structure clear to thy
>     fellow man by using the One True Brace Style, even if thou likest
>     it not, for thy creativity is better used in solving problems than
>     in creating beautiful new impediments to understanding.
> 
> And that's what "0 == foo" is: an impediment to understanding.

It's got nothing to do with visual scanning.  It's more to do with 
grammatical form i.e. we (especially English speakers) like the form: 
subject (foo) verb (==) object (0); and in these cases the variable 
(foo) is the indisputable subject (i.e. the thing the sentence is about) 
but (0 == foo) momentarily causes us to think that 0 is the subject and 
we find this disconcerting.  On the other hand, Yoda (the Jedi master) 
would probably prefer: (0 foo ==) :-)

Like most matters of style there are points for and against both methods 
  and eventually someone has to make a (relatively arbitrary) decision. 
  Linus has made the decision and it's his call so we should abide by it 
(especially since he made it pretty clear that he was aware of (and 
considered) all the relevant arguments and is therefore unlikely to 
change his mind).

Peter
PS It's important not to get too emotionally attached to a particular 
method or style because there's always a chance that whoever gets to 
decide which will be used may not choose the one you like.  This time 
you lucked in :-)
-- 
Dr Peter Williams, Chief Scientist                peterw@aurema.com
Aurema Pty Limited                                Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia  Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com

Re: (0 == foo), rather than (foo == 0)

[Chris Johns]

Just to throw a little more gas on this particular fire (or maybe
some water, depending on your point of view), when I worked for a while
at the Evil Empire, the "const == variable" comparison was mandatory in
the group I worked in. Odd to look at initially, I'll admit, but it 
still caught
several potential bugs. One other thing that was mandatory was to
set to NULL any pointer to memory area that was freed immediately after
freeing it. Again, a good idea, although not a coding style issue.

Chris


On Mar 11, 2004, at 10:44 AM, Chip Salzenberg wrote:

> Amarendra.Godbole@ge.com writes:
>>> As a result, using the former just tends to increase peoples
>>> confusion by making code harder to read, which in turn tends
>>> to increase the chance of bugs.
>>
>> Kindly don't insult the kernel developers' with such statements. ;-)
>> They are smart enough to understand such constructs [...]
>
> It's not about intelligence!  It's about the nature of human visual
> pattern-matching.  Reading a pattern is always easier when you've seen
> it thousands of times before.
>
> Henry Spencer's dictum about brace style seems particularly apropos:
>
> 8.  Thou shalt make thy program's purpose and structure clear to thy
>     fellow man by using the One True Brace Style, even if thou likest
>     it not, for thy creativity is better used in solving problems than
>     in creating beautiful new impediments to understanding.
>
> And that's what "0 == foo" is: an impediment to understanding.
> -- 
> Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
> "I wanted to play hopscotch with the impenetrable mystery of existence,
>     but he stepped in a wormhole and had to go in early."  // MST3K
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: (0 == foo), rather than (foo == 0)

[Richard B. Johnson]

On Thu, 11 Mar 2004, Chris Johns wrote:

> Just to throw a little more gas on this particular fire (or maybe
> some water, depending on your point of view), when I worked for a while
> at the Evil Empire, the "const == variable" comparison was mandatory in
> the group I worked in. Odd to look at initially, I'll admit, but it
> still caught
> several potential bugs. One other thing that was mandatory was to
> set to NULL any pointer to memory area that was freed immediately after
> freeing it. Again, a good idea, although not a coding style issue.
>
> Chris
>

Well I'll take it as being proof that forcing a particular style
doesn't help make bug-free code since it didn't help Microsoft.

I'll bet that Microsoft has more bugs per KLOC than any other
software, ever. It is a formidable challenge to make software
that will beat it in that area. You really need to try. You
need to be cunning enough to get it through the compile-stage.
It's an art.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.