From: Krzysztof Halasa <khc@pm.waw.pl>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Harvey Harrison" <harvey.harrison@gmail.com>,
"Håkon Løvdal" <hlovdal@gmail.com>,
"Hannes Eder" <hannes@hanneseder.net>,
netdev@vger.kernel.org, kernel-janitors@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 02/27] drivers/net: fix sparse warnings: make do-while a compound statement
Date: Wed, 24 Dec 2008 03:03:50 +0100 [thread overview]
Message-ID: <m3myemqqgp.fsf@maximus.localdomain> (raw)
In-Reply-To: <alpine.LFD.2.00.0812231529030.3535@localhost.localdomain> (Linus Torvalds's message of "Tue\, 23 Dec 2008 15\:38\:02 -0800 \(PST\)")
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Oh yes it can. People look at that, and it's so uncommon that they
> literally believe it is a mis-indent.
People learn, or should, through the life :-)
I'm not sure being common or less common does matter here much.
OTOH I think it's pretty common. Approx as common as while (x) y is,
isn't it?
Except in macros: do-while(0) is commonly used in macros because it
"eats" the semicolon.
(do { xxx; yyy; zzz } while (0) is also quite common instead of "goto"
to add multiple exits from a long block).
> Your example with nested if-statements are totally pointless, because you
> didn't even apparently understand my comment about "while()" having two
> totally different meanings (which is not true of "if()"), nor realize the
> importance of how common something is.
Only apparently. If there is no ambiguity, there is no problem, the
double meaning does not seem relevant.
You tell me that
do
expr;
while (condition);
(with precisely this formatting) can be unclear?
Or you say
do {
expr;
} while (condition);
is better? If it is, then certainly not for me.
Now: are we going to write {} because you say so, even if it makes the
code worse? Or should we rather aim at improving the code, even if
only a bit? (I admit that, IMO, the second example is worse = less
readable, but only a small bit).
> Sorry, you're wrong. It's not changed to silence some tool.
Come on, you have it plain in the subject - "fix sparse warnings".
If it was "improve obscure notation" I wouldn't say a word.
> And I agree with you. "sizeof i" doesn't look good. It's uncommon, and
> doesn't match peoples expectations.
But it doesn't matter if it's common or not. It doesn't look good and
THIS IS WHY it's uncommon/nonexistent. Not the other way around.
There are many uncommon things in a project like a Linux kernel. There
are some macros which take me a while :-) to understand and they
thankfully don't spew warnings.
> Another example of "common vs non-common" is this:
>
> if (0 <= x)
> do something..
>
> is something that crazy people do (sadly, one of the crazy people taught
> the git maintainer C programming, so now even sane people do it). It's
> crazy because it's uncommon, which means that most people have to think
> about it A LOT MORE than about
>
> if (x >= 0)
> do something..
No. It's crazy not because it's uncommon, but because this is how we
have been taught in school.
I don't know reasons for "0 >= x" but I know one for
if (0 == x)
do something..
It's because people sometimes write "=" instead of "==" and "0 = x"
doesn't make sense to gcc. I think it's not a valid reason, and
(unless you use (()) which is IMHO also crazy) gcc will warn about
if (x = 0) (though I think the warning is stupid and "if (a = b)"
is a valid usage if a and b are short).
It's simple: one has to see the difference between if (x = 0) vs
if (x == 0), there is no way around it. if (0 >= x), I don't know.
> Can you see the argument? Doing things the common way is important,
> because it allows people to see what they mean without having to think
> about it. They just scan it, and the meaning is clear.
Then I must be different. Things are clear to me if they are clear,
even if they are uncommon. And common things aren't necessarily clear.
Hmm, I should have expected something like that.
> And that's why "do while" without braces is bad. If you scan it quickly on
> its own, you may well end up just seeing the
>
> while (x);
>
> part, and get confused ("oh, a delay loop").
Nope.
It raises a red flag in my head immediately. We don't do such busy
loops generally, and if we do, I would write it as:
while (x)
;
> But if you see
>
> } while (x);
>
> you aren't confused, because the latter one is clearly an ending condition
> of a do-while loop, IN A WAY THAT THE FIRST ONE IS NOT!
>
> See?
No. I must be different.
> do-while is very special, because as mentioned, "while" is a really magic
> C keyword that has two TOTALLY DIFFERENT meanings.
Probably. I just don't see it.
For me, every code fragment is different, and a program like sparse
can't even come close to know what's clear for me and what is not.
I use sparse as a great help - but only that, a help.
--
Krzysztof Halasa
next prev parent reply other threads:[~2008-12-24 2:03 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-22 19:14 [PATCH 00/27] drivers/net: fix sparse warnings Hannes Eder
2008-12-22 19:14 ` [PATCH 01/27] drivers/net: fix sparse warning: use ANSI-style function declaration Hannes Eder
2008-12-26 7:53 ` David Miller
2008-12-22 19:15 ` [PATCH 02/27] drivers/net: fix sparse warnings: make do-while a compound statement Hannes Eder
2008-12-22 22:14 ` Krzysztof Halasa
2008-12-22 23:44 ` Håkon Løvdal
2008-12-23 16:31 ` Krzysztof Halasa
2008-12-23 17:26 ` Harvey Harrison
2008-12-23 17:36 ` Krzysztof Halasa
2008-12-23 18:08 ` Linus Torvalds
2008-12-23 23:18 ` Krzysztof Halasa
2008-12-23 23:38 ` Linus Torvalds
2008-12-24 2:03 ` Krzysztof Halasa [this message]
2008-12-24 2:10 ` Linus Torvalds
2008-12-25 17:02 ` Krzysztof Halasa
2008-12-25 6:17 ` Junio C Hamano
2008-12-29 14:35 ` Hannes Eder
2008-12-26 7:55 ` David Miller
2008-12-22 19:15 ` [PATCH 03/27] drivers/net: fix sparse warning: returning void-valued expression Hannes Eder
2008-12-26 0:17 ` David Miller
2008-12-26 14:39 ` Hannes Eder
2008-12-26 19:59 ` Randy Dunlap
2008-12-27 19:11 ` Hannes Eder
2008-12-27 19:20 ` Sam Ravnborg
2008-12-27 21:38 ` [PATCH] Makefile: disable sparse warning "returning void-valued expression" Hannes Eder
2008-12-27 21:57 ` Sam Ravnborg
2008-12-26 7:56 ` [PATCH 03/27] drivers/net: fix sparse warning: returning void-valued expression David Miller
2008-12-22 19:15 ` [PATCH 04/27] drivers/net: fix sparse warnings: make symbols static Hannes Eder
2008-12-26 7:57 ` David Miller
2008-12-22 19:15 ` [PATCH 05/27] drivers/net/arcnet: " Hannes Eder
2008-12-26 7:57 ` David Miller
2008-12-22 19:15 ` [PATCH 06/27] drivers/net/atlx: " Hannes Eder
2008-12-26 7:58 ` David Miller
2008-12-22 19:15 ` [PATCH 07/27] drivers/net/bonding: fix sparse warnings: move decls to header file Hannes Eder
2008-12-26 7:59 ` David Miller
2008-12-22 19:16 ` [PATCH 08/27] drivers/net/cxgb3: comment out dead code Hannes Eder
2008-12-26 7:59 ` David Miller
2008-12-22 19:16 ` [PATCH 09/27] drivers/net/e1000e: fix sparse warnings: make symbols static Hannes Eder
2008-12-22 19:16 ` [PATCH 10/27] drivers/net/enic: fix sparse warning: make symbol static Hannes Eder
2008-12-26 8:01 ` David Miller
2008-12-22 19:16 ` [PATCH 11/27] drivers/net/igb: remove dead code (function 'igb_read_pci_cfg') Hannes Eder
2008-12-22 22:30 ` Jeff Kirsher
2008-12-26 8:03 ` David Miller
2008-12-22 19:16 ` [PATCH 12/27] drivers/net/irda: fix sparse warnings: make symbols static Hannes Eder
2008-12-26 8:03 ` David Miller
2008-12-22 19:16 ` [PATCH 13/27] drivers/net/ixgbe: " Hannes Eder
2008-12-26 8:04 ` David Miller
2008-12-22 19:16 ` [PATCH 14/27] drivers/net/netxen: fix sparse warnings: use NULL pointer instead of plain integer Hannes Eder
2008-12-26 8:04 ` David Miller
2008-12-22 19:17 ` [PATCH 15/27] drivers/net/qlge: fix sparse warnings: make symbols static Hannes Eder
2008-12-26 8:05 ` David Miller
2008-12-22 19:17 ` [PATCH 16/27] drivers/net/skfp: " Hannes Eder
2008-12-26 8:06 ` David Miller
2008-12-22 19:17 ` [PATCH 17/27] drivers/net/tokenring: " Hannes Eder
2008-12-26 8:07 ` David Miller
2008-12-22 19:17 ` [PATCH 18/27] drivers/net/tulip: fix sparse warnings: make do-while a compound statement Hannes Eder
2008-12-26 8:07 ` David Miller
2008-12-22 19:17 ` [PATCH 19/27] drivers/net/usb: fix sparse warnings: make symbols static Hannes Eder
2008-12-26 8:08 ` David Miller
2008-12-22 19:17 ` [PATCH 20/27] drivers/net/wan: fix sparse warnings: make do-while a compound statement Hannes Eder
2008-12-22 22:09 ` Krzysztof Halasa
2008-12-22 19:18 ` [PATCH 21/27] drivers/net/wan: fix sparse warning: make symbol static Hannes Eder
2008-12-26 8:11 ` David Miller
2008-12-22 19:18 ` [PATCH 22/27] drivers/net/wan/z85230.c: fix sparse warnings: un-EXPORT symbols Hannes Eder
2008-12-26 8:12 ` David Miller
2008-12-22 19:18 ` [PATCH 23/27] drivers/net/wireless: fix sparse warnings: make symbols static Hannes Eder
2008-12-26 8:13 ` David Miller
2008-12-22 19:18 ` [PATCH 24/27] drivers/net/wireless/ath9k: " Hannes Eder
2008-12-22 19:18 ` [PATCH 25/27] drivers/net/wireless/b43: " Hannes Eder
2008-12-26 8:13 ` David Miller
2008-12-22 19:18 ` [PATCH 26/27] drivers/net/wireless/ipw2x00: " Hannes Eder
2008-12-26 8:14 ` David Miller
2008-12-22 19:19 ` [PATCH 27/27] drivers/net/wireless/prism54: " Hannes Eder
2008-12-26 8:15 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3myemqqgp.fsf@maximus.localdomain \
--to=khc@pm.waw.pl \
--cc=hannes@hanneseder.net \
--cc=harvey.harrison@gmail.com \
--cc=hlovdal@gmail.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox