[PATCH 1/2] introduce-fiq-hdq.patch

[Werner Almesberger]

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

	char buf[FOO];
...
	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
anymore ;-))

- Werner