Hi Andrew,
your commit e2c2770096b686b4d2456173f53cb50e01aa635c does this:
---
Always use do {} while (0). Failing to do so can cause subtle compile
failures or bugs.
-#define hotcpu_notifier(fn, pri)
-#define register_hotcpu_notifier(nb)
-#define unregister_hotcpu_notifier(nb)
+#define hotcpu_notifier(fn, pri) do { } while (0)
+#define register_hotcpu_notifier(nb) do { } while (0)
+#define unregister_hotcpu_notifier(nb) do { } while (0)
---
I'm really wondering what these subtle compile failures or bugs are.
Could you please explain?
On 01/08/06, Heiko Carstens <[email protected]> wrote:
> ---
> Always use do {} while (0). Failing to do so can cause subtle compile
> failures or bugs.
> ---
>
> I'm really wondering what these subtle compile failures or bugs are.
> Could you please explain?
http://kernelnewbies.org/FAQ/DoWhile0
cheers,
Jonathan
--
Jonathan Matthews-Levine
e: [email protected]
On Tue, 1 Aug 2006 10:21:09 +0200
Heiko Carstens <[email protected]> wrote:
> Hi Andrew,
>
> your commit e2c2770096b686b4d2456173f53cb50e01aa635c does this:
>
> ---
> Always use do {} while (0). Failing to do so can cause subtle compile
> failures or bugs.
>
> -#define hotcpu_notifier(fn, pri)
> -#define register_hotcpu_notifier(nb)
> -#define unregister_hotcpu_notifier(nb)
> +#define hotcpu_notifier(fn, pri) do { } while (0)
> +#define register_hotcpu_notifier(nb) do { } while (0)
> +#define unregister_hotcpu_notifier(nb) do { } while (0)
<strains brain>
Can't remember. Maybe it's OK in this case.
Would it be too weazelly to say "because CodingStyle says to"? ;)
Heiko Carstens wrote:
> Hi Andrew,
>
> your commit e2c2770096b686b4d2456173f53cb50e01aa635c does this:
>
> ---
> Always use do {} while (0). Failing to do so can cause subtle compile
> failures or bugs.
>
> -#define hotcpu_notifier(fn, pri)
> -#define register_hotcpu_notifier(nb)
> -#define unregister_hotcpu_notifier(nb)
> +#define hotcpu_notifier(fn, pri) do { } while (0)
> +#define register_hotcpu_notifier(nb) do { } while (0)
> +#define unregister_hotcpu_notifier(nb) do { } while (0)
#if KILLER == 1
#define MACRO
#else
#define MACRO do { } while (0)
#endif
{
if (some_condition)
MACRO
if_this_is_not_called_you_loose_your_data();
}
How do you want to define KILLER, 0 or 1? I personally choose 0.
regards,
--
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
On Tue, Aug 01, 2006 at 09:45:26AM +0100, Jonathan Matthews-Levine wrote:
> On 01/08/06, Heiko Carstens <[email protected]> wrote:
> >---
> >Always use do {} while (0). Failing to do so can cause subtle compile
> >failures or bugs.
> >---
> >
> >I'm really wondering what these subtle compile failures or bugs are.
> >Could you please explain?
>
> http://kernelnewbies.org/FAQ/DoWhile0
My question was referring to empty do { } while (0)'s... that's something
the FAQ is not dealing with :)
> #if KILLER == 1
> #define MACRO
> #else
> #define MACRO do { } while (0)
> #endif
>
> {
> if (some_condition)
> MACRO
>
> if_this_is_not_called_you_loose_your_data();
> }
>
> How do you want to define KILLER, 0 or 1? I personally choose 0.
Really? Does it compile?
Hua
On Tue, 2006-08-01 at 02:03 -0700, Hua Zhong wrote:
> > #if KILLER == 1
> > #define MACRO
> > #else
> > #define MACRO do { } while (0)
> > #endif
> >
> > {
> > if (some_condition)
> > MACRO
> >
> > if_this_is_not_called_you_loose_your_data();
> > }
> >
> > How do you want to define KILLER, 0 or 1? I personally choose 0.
>
> Really? Does it compile?
No, and that is the whole point.
The empty 'do {} while (0)' makes the missing semicolon a syntax error.
Peter Zijlstra wrote:
> On Tue, 2006-08-01 at 02:03 -0700, Hua Zhong wrote:
>>> #if KILLER == 1
>>> #define MACRO
>>> #else
>>> #define MACRO do { } while (0)
>>> #endif
>>>
>>> {
>>> if (some_condition)
>>> MACRO
>>>
>>> if_this_is_not_called_you_loose_your_data();
>>> }
>>>
>>> How do you want to define KILLER, 0 or 1? I personally choose 0.
>> Really? Does it compile?
>
> No, and that is the whole point.
>
> The empty 'do {} while (0)' makes the missing semicolon a syntax error.
Bulls^WNope, it was a bad example (we don't want to break the compilation, just
not want to emit a warn or an err).
I can't emit an error with the thing like that, only a warning, but we are not
using -Werror to get err from a warn. Thing such this would emit empty-statement
warn if define KILLER as 1:
#if KILLER == 1
#define MACRO
#else
#define MACRO do { } while (0)
#endif
{
if (some_condition)
MACRO;
else
do_something();
}
regards,
--
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
On Tue, Aug 01, 2006 at 11:45:53AM +0159, Jiri Slaby wrote:
> Peter Zijlstra wrote:
> >On Tue, 2006-08-01 at 02:03 -0700, Hua Zhong wrote:
> >>>#if KILLER == 1
> >>>#define MACRO
> >>>#else
> >>>#define MACRO do { } while (0)
> >>>#endif
> >>>
> >>>{
> >>> if (some_condition)
> >>> MACRO
> >>>
> >>> if_this_is_not_called_you_loose_your_data();
> >>>}
> >>>
> >>>How do you want to define KILLER, 0 or 1? I personally choose 0.
> >>Really? Does it compile?
> >
> >No, and that is the whole point.
> >
> >The empty 'do {} while (0)' makes the missing semicolon a syntax error.
>
> Bulls^WNope, it was a bad example (we don't want to break the compilation,
> just not want to emit a warn or an err).
Your sentence does not make sense, but I'm going to take it as saying
that you disagree that the above will cause a syntax error. Try it:
$ cat t.c
#if KILLER == 1
#define MACRO
#else
#define MACRO do { } while (0)
#endif
void foo(int some_condition)
{
if (some_condition)
MACRO
if_this_is_not_called_you_loose_your_data();
}
$ gcc -O2 -o - -E t.c
# 1 "t.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "t.c"
void foo(int some_condition)
{
if (some_condition)
do { } while (0)
if_this_is_not_called_you_loose_your_data();
}
$ gcc -O2 -o - -S t.c >/dev/null
t.c: In function `foo':
t.c:12: error: parse error before "if_this_is_not_called_you_loose_your_data"
$ gcc -O2 -o - -E t.c -DKILLER
# 1 "t.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "t.c"
void foo(int some_condition)
{
if (some_condition)
if_this_is_not_called_you_loose_your_data();
}
$ gcc -O2 -o - -S t.c -DKILLER >/dev/null
$
Hence, using do { } while (0) has had the desired effect - the missing
semicolon causes a compile error, while the empty macro results in
unintentional successful compilation without warning or error.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Tue, 2006-08-01 at 11:45 +0159, Jiri Slaby wrote:
> Peter Zijlstra wrote:
> > On Tue, 2006-08-01 at 02:03 -0700, Hua Zhong wrote:
> >>> #if KILLER == 1
> >>> #define MACRO
> >>> #else
> >>> #define MACRO do { } while (0)
> >>> #endif
> >>>
> >>> {
> >>> if (some_condition)
> >>> MACRO
> >>>
> >>> if_this_is_not_called_you_loose_your_data();
> >>> }
> >>>
> >>> How do you want to define KILLER, 0 or 1? I personally choose 0.
> >> Really? Does it compile?
> >
> > No, and that is the whole point.
> >
> > The empty 'do {} while (0)' makes the missing semicolon a syntax error.
>
> Bulls^WNope, it was a bad example (we don't want to break the compilation, just
> not want to emit a warn or an err).
It was a perfectly good example why 'do {} while (0)' is useful. The
perhaps mistakenly forgotten ';' after MACRO will not stop your example
from compiling if KILLER == 1. Even worse, it will compile and do
something totally unexpected.
If however you use KILLER != 1, the while(0) will require a ';' and this
example will fail to compile.
Not compiling when you made a coding error (forgetting ';' is one of the
most common) is a great help.
Peter Zijlstra wrote:
> On Tue, 2006-08-01 at 11:45 +0159, Jiri Slaby wrote:
>> Peter Zijlstra wrote:
>>> On Tue, 2006-08-01 at 02:03 -0700, Hua Zhong wrote:
>>>>> #if KILLER == 1
>>>>> #define MACRO
>>>>> #else
>>>>> #define MACRO do { } while (0)
>>>>> #endif
>>>>>
>>>>> {
>>>>> if (some_condition)
>>>>> MACRO
>>>>>
>>>>> if_this_is_not_called_you_loose_your_data();
>>>>> }
>>>>>
>>>>> How do you want to define KILLER, 0 or 1? I personally choose 0.
>>>> Really? Does it compile?
>>> No, and that is the whole point.
>>>
>>> The empty 'do {} while (0)' makes the missing semicolon a syntax error.
>> Bulls^WNope, it was a bad example (we don't want to break the compilation, just
>> not want to emit a warn or an err).
>
> It was a perfectly good example why 'do {} while (0)' is useful. The
> perhaps mistakenly forgotten ';' after MACRO will not stop your example
> from compiling if KILLER == 1. Even worse, it will compile and do
> something totally unexpected.
>
> If however you use KILLER != 1, the while(0) will require a ';' and this
> example will fail to compile.
That's what I'm trying to say. It was a _bad_ piece of code. It doesn't
demonstrate I want it to demonstrate.
> Not compiling when you made a coding error (forgetting ';' is one of the
> most common) is a great help.
regards,
--
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
Russell King wrote:
> On Tue, Aug 01, 2006 at 11:45:53AM +0159, Jiri Slaby wrote:
>> Peter Zijlstra wrote:
>>> On Tue, 2006-08-01 at 02:03 -0700, Hua Zhong wrote:
>>>>> #if KILLER == 1
>>>>> #define MACRO
>>>>> #else
>>>>> #define MACRO do { } while (0)
>>>>> #endif
>>>>>
>>>>> {
>>>>> if (some_condition)
>>>>> MACRO
>>>>>
>>>>> if_this_is_not_called_you_loose_your_data();
>>>>> }
>>>>>
>>>>> How do you want to define KILLER, 0 or 1? I personally choose 0.
>>>> Really? Does it compile?
>>> No, and that is the whole point.
>>>
>>> The empty 'do {} while (0)' makes the missing semicolon a syntax error.
>> Bulls^WNope, it was a bad example (we don't want to break the compilation,
>> just not want to emit a warn or an err).
>
> Your sentence does not make sense, but I'm going to take it as saying
> that you disagree that the above will cause a syntax error. Try it:
No, my code is bad, not his thoughts.
regards,
--
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
Jiri Slaby <[email protected]> wrote:
> Heiko Carstens wrote:
> > Hi Andrew,
> > your commit e2c2770096b686b4d2456173f53cb50e01aa635c does this:
> > ---
> > Always use do {} while (0). Failing to do so can cause subtle compile
> > failures or bugs.
> > -#define hotcpu_notifier(fn, pri)
> > -#define register_hotcpu_notifier(nb)
> > -#define unregister_hotcpu_notifier(nb)
> > +#define hotcpu_notifier(fn, pri) do { } while (0)
> > +#define register_hotcpu_notifier(nb) do { } while (0)
> > +#define unregister_hotcpu_notifier(nb) do { } while (0)
>
> #if KILLER == 1
> #define MACRO
> #else
> #define MACRO do { } while (0)
> #endif
>
> {
> if (some_condition)
> MACRO
; /* missing */
>
> if_this_is_not_called_you_loose_your_data();
> }
> How do you want to define KILLER, 0 or 1? I personally choose 0.
Yep, at least in this case you'd get a compile failure.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
On Tuesday 01 August 2006 04:53, Heiko Carstens wrote:
> On Tue, Aug 01, 2006 at 09:45:26AM +0100, Jonathan Matthews-Levine wrote:
> > On 01/08/06, Heiko Carstens <[email protected]> wrote:
> > >---
> > >Always use do {} while (0). Failing to do so can cause subtle compile
> > >failures or bugs.
> > >---
> > >
> > >I'm really wondering what these subtle compile failures or bugs are.
> > >Could you please explain?
> >
> > http://kernelnewbies.org/FAQ/DoWhile0
>
> My question was referring to empty do { } while (0)'s... that's something
> the FAQ is not dealing with :)
For readers and writers familiar with the idiom, it is easier to use
it for all macros intended to act like statements. Its presence will
actually be less suprising than its absence, even in situations when
it doesn't actually change anything.
Andrew Wade