a simple question

[MichaelLee]

I just begin reading some kernel source code , i found some funny thing i don't understand :

for example :

#define spin_lock_irqsave(lock, flags) do { local_irq_save(flags); spin_lock(lock); } while (0)

what the "do{...}while(0)" for ?
The while(0) here seems not necessary. Is it stand for some compile trick?

thanks!!

[Mikey]

I'm not a programmer, but it looks to me that it will do whatever while there is no error

Now, we'll see if I'm right when a programming person responds...

[sarumont]

#define spin_lock_irqsave(lock, flags) do { local_irq_save(flags); spin_lock(lock); } while (0)

what the "do{...}while(0)" for ?
The while(0) here seems not necessary. Is it stand for some compile trick?

thanks!!

This just tellsit to execute the loop once and then stop. while(0) evaluates to false in C, so the loop won't run after the initial execution.

[Stormhawk]

The only advantage to this over a piece of code without the { ... } and while(0) is that with them its better contained; from a source-readability point of view. Its just for aesthetics; code tidiness. The compiler will (or, should) optimise away the do... while bit, as its only ever done once.

[sigsegv]

This is a coding trick to get a function like behaviour from a macro
spin_lock_irqsave() is defined as a macro with parameters. It's natural to place a simicolon at the end as if spin_lock_irqsave() were really a function. If you had:

#define spin_lock_irqsave(lock, flags) { local_irq_save(flags); spin_lock(lock); }

Then calling:

spin_lock_irqsave(1, 2);

would expand to:

{ local_irq_save(2); spin_lock(1) };

And this would cause an error, since we have an extra emicolon at the end. A better way would be to place everything in the empty do-while() loop and that would consume that extra semicolon:

#define spin_lock_irqsave(lock, flags) do { local_irq_save(flags); spin_lock(lock); } while (0)

[narendrakiran]

Let's take an example where the given piece of macro is illegal without using do...while() construct.

#define spin_lock_irqsave(lock, flags) { local_irq_save(flags); spin_lock(lock); }

if(......)
spin_lock_irqsave(&lock, flags);
else
........


The preprocessor will expand this code as


if(......)
{ local_irq_save(flags); spin_lock(lock); }; //Observe the extra-semicolon
else
........


Now due to the extra semicolon, the if...else construct is not recognized as one block, leading to compilation error. This could be prevented if do...while() construct is used in the macro

#define spin_lock_irqsave(lock, flags) do { local_irq_save(flags); spin_lock(lock); } while (0)

Now the given code will be expanded to

if(......)
do { local_irq_save(flags); spin_lock(lock); }while(0); //extra-semicolon has no effect
else
........



The do...while() acts as a single semantic block and hence the compiler recognizes the if...else construct as expected.

Regards,
Narendra Kiran Ch,
Vindynamics Software Eng Pvt Ltd, Bangalore.

[bitzilla]

Haah, I know it, too!!

thanks!!!!