[PATCH 1/2] introduce-fiq-hdq.patch
werner at openmoko.org
Fri Feb 15 12:53:47 CET 2008
Andy Green wrote:
> But the space after casts is super over-pedantic, the kernel is
> absolutely chock full of the style I used there and CodingStyle is
> silent about it, so I will keep that.
CodingStyle doesn't have all the rules, but K&R is generally a very
good guide (okay, don't look at page 62 ;-) Alas, there's a lot of
code in the kernel that doesn't play by the rules :-(
> and only improves readability, I will keep this (but I will think about
> it from now on in case I am being a stick-in-the-mud).
Good ;-) I'm not so sure parentheses improve readability - to me,
they usually suggest "I did something that _needs_ parentheses",
so I stop and give the expression a closer look.
I guess it's a question where you draw the line when precedence
rules become non-intuitive. E.g., the possible effects of = or
& and | are confusing, so it makes sense that gcc even warns about
them, and requires (possible redundant) parentheses.
>> where reasonably possible. (Rationale, as far as I remember it: on
>> some platforms, testing for equality is more efficient than testing
>> for order. Also, a test for equality is less likely to mask errors
> I find this rationale very hard to believe :-) But changed.
Thanks ! For the masked errors, one example would be this:
#define FOO 40
for (i = 0; i < sizeof(buf); i += 4)
... (uint32_t *) (buf+i) ...
/* so some work on it in four byte chunks */
Now that's perfectly valid. (If you don't like the cast, this could
also be a copy to a four-byte object, so something similar.) However,
if later on, someone changes "foo" to
char buf[FOO+1]; /* room for a terminating NUL */
the "<" loop will still terminate, and you may not even notice what's
going on. A loop that tests for != would run endlessly, immediately
making one aware that something's wrong.
(There's been a huge discussion about this on linux-kernel some
years ago. Also examples in favour of "<" were made. I found them
a bit less convincing, though, so I don't even remember them
More information about the openmoko-kernel