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>
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
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
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.
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.
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
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.
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
>
>
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.
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.
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.
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 | [email protected]
Roland Dreier <[email protected]> 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
[email protected]
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.
[email protected] wrote:
>Kindly piss off. My mail reading software uses vi(1) to compose the
>reply and has enough sense to preserve the line boundaries.
>
>
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?
> [email protected] 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.
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.
>
> [email protected] 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
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 [email protected]
> 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 [email protected]
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
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 [email protected]
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
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
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
David Ford <[email protected]> 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
[email protected]
Frank v Waveren <[email protected]> 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
[email protected]
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
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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.
>
>
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
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
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 [email protected]
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
> 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.
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
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
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 [email protected]
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
Stefan Smietanowski <[email protected]> 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
[email protected]
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
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)
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?
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.
[email protected] (M?ns Rullg?rd) writes:
> Stefan Smietanowski <[email protected]> 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, [email protected]
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."
On Thu, 11 Mar 2004 [email protected] 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.
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???
[email protected] 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. - <[email protected]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
[email protected] 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. - <[email protected]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
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
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
M?ns Rullg?rd wrote:
> Roland Dreier <[email protected]> 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
Chip Salzenberg wrote:
> [email protected] 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 [email protected]
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
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:
> [email protected] 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. - <[email protected]>
> "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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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.