On 02/06/2009 04:53 PM, Michael ODonnell wrote:
What I see confufsing is:
do { ... } while(0);
What this means is to go through the loop once. You need a leading
curly so you can set up counter as a local variable as variable
names are block scope. { ... } would be equivalent to above.
> But if you change the macro to:
> #define b0rken(x) ({return x;})
> you will find that the compiler likes it again.
I mistakenly interpreted your statement that the two constructions
are equivalent:
> What I see confufsing is:
> do { ... } while(0);
[...]
> { ... } would be eq
On 02/07/2009 09:56 AM, Michael ODonnell wrote:
But if you change the macro to:
#define b0rken(x) ({return x;})
you will find that the compiler likes it again.
I mistakenly interpreted your statement that the two constructions
are equivalent:
What I see confufsing is:
do { ... } wh
> The bottom line is that in the section of code you presented,
> what was important was to establish a block so a variable could
> be defined. Adding the do while(0) is just adding
> some extraneous code that would be most probably optimized out,
> but even if it is not, it is in an error cond
On 02/07/2009 10:55 AM, Michael ODonnell wrote:
I suspect that whoever added that code to the kernel cribbed it
from elsewhere without understanding (or maybe not caring whether
they understood) it. At any rate, I wasn't concerned about that
do-while(0) construct so much as the apparent randomne
> I'm not sure if kernel printfs are enabled in production kernels.
> I forget how they are configured, so it is possible that no-one
> will ever see the message.
They're enabled - that's what drew my attention to that code
in the first place. The 32bit version of libraw1394 apparently
uses ioc
On 02/07/2009 12:04 PM, Michael ODonnell wrote:
I'm not sure if kernel printfs are enabled in production kernels.
I forget how they are configured, so it is possible that no-one
will ever see the message.
They're enabled - that's what drew my attention to that code
in the first place.
