Sparse warns about do-while loops without braces; Linus's rationale from the
Signed-off-by: Josh Triplett <josh@kernel.org>

---

 Documentation/CodingStyle |    7 +++++++

 1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle

index 7f1730f..f12e4b8 100644

--- a/Documentation/CodingStyle

+++ b/Documentation/CodingStyle

@@ -175,6 +175,13 @@ if (condition) {

 	otherwise();

 }
+This also does not apply to a do-while loop; always use braces with a do-while,

+even if it contains a single statement:

+

+do {

+	this();

+} while(condition);

+

 		3.1:  Spaces
 Linux kernel style for use of spaces depends (mostly) on

--

1.5.2.1
-

I can't see anything wrong with
do

	abc;

while (xyz);
and even if I could, "always use" seems way too strong in this case.

--

Krzysztof Halasa

-

Besides, how about reorienting the CodingStyle text to the essential?
(But leave the humorous language in --- the few parts that are inherited

from old versions of that file, now more and more being buried in dry

nitpicking.)

--

Stefan Richter

-=====-=-=== -=== ==-==

http://arcgraph.de/sr/

-

---

~Randy

*** Remember to use Documentation/SubmitChecklist when testing your code ***

-

If sparse has gone and added a warning for this then it is more than

nitpicking.  Reducing the amount of noise coming out of sparse is useful.

-

Sure, that'd be useful.  But then, SubmitChecklist already tells us to

check with sparse before submission.

--

Stefan Richter

-=====-=-=== -=== ==-==

http://arcgraph.de/sr/

-

rofl.  First we have to talk everyone into checking their stuff with gcc.
-

Ah, I forgot --- Real Submitters don't compile their code before

submission.  But wait, they also don't track CodingStyle.
Seriously though:  Precise rules are a priori welcome.  But the more

rules there are, the less of them we (authors, reviewers) can memorize.

If we go for having many rules, then we need to rely more on checkpatch

and sparse.  When growing into a catch-all rule book, the utility of

CodingStyle will shift from an author's guide to a specification for

code checking tools.

--

Stefan Richter

-=====-=-=== -=== ==-==

http://arcgraph.de/sr/

-

it's better that we all do things the same way.  What that way _is_ is

actually less important, unless it's something stupid, of course.
In this case, most of the code I've seen uses the braces (I think).
-

It's certainly true WRT things like indentation but IMHO it shouldn't

go that far, and if it goes, it should be non-braced version.
If we prefer non-braced versions of "if" and "while", it would be

a bit strange to require braces with "do while", wouldn't it?
Sparse warnings... I think it shouldn't complain either, unless

called with extra parameter.
Perhaps some pointer to a bad-looking example so I can see for myself?

--

Krzysztof Halasa

-

Perhaps, but

     1. Existing kernel style uses braces with single-statement

        do-while.

     2. Linus prefers (or at least preferred in October of 2006) braces
Good point; Sparse shouldn't warn about this by default.  I've turned

that off in latest Sparse from Git, so you need to give -Wdo-while or

-Wall to get warnings about that.  However, the kernel gives -Wall, so

you'll still see the warnings there.
- Josh Triplett
-

On Fri, 27 Jul 2007 10:05:16 -0700
I believe reeducating sparse was the best fix here.  I think I'll now

have a quiet accident with codingstyle-proscribe-do-while-without-braces.patch

-

I didn't just submit the patch because Sparse warns about it.  I

submitted the patch because of the coding style preference that led to

the Sparse warning.
Also, if this really *shouldn't* form part of the kernel style, then the

kernel should use -Wno-do-while with -Wall, or should stop using -Wall.
That said, I don't care all that much about the patch, so I won't push

further for it one way or another.
- Josh Triplett
-

Fine with me, but it should IMHO be maintainer's call.
Things which a) are clearly better, and/or b) would require massive

reformatting when new maintainer steps in, should be documented

in CodingStyle and perhaps checked for by scripts and sparse.
Other things... sometimes there are multiple ways to do something

well, and humans aren't, and shouldn't be that deterministic.

--

Krzysztof Halasa

-

err, your example has broken coding style.

-

Oops; thanks for catching that. :)
- Josh Triplett
-