Netdev List
 help / color / mirror / Atom feed
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

  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