Use of do...while(0) in ASSERT macro

[Martin]

Can anyone help with a quick query...

I've seen the ASSERT macro defined as:
#define ASSERT(f) \
do { \
if (!(f) && assertFailedOnL ine (THIS_FILE, __LINE__)) \
FatalExit (0); \
} while (0) \
When I comple this in debug mode the compiler warns "conditiona l
expression is constant", because of the while (0). Why is the ASSERT
macro defined this way? The loop only runs once so why not get rid of
the do..while and use:
#define ASSERT(f) \
if (!(f) && assertFailedOnL ine (THIS_FILE, __LINE__)) \
FatalExit (0); \
This also gets rid of the compiler warning.

Is there any reason to use the first definition?

Martin

[Derk Gwen]

mr*****@totalis e.co.uk (Martin) wrote:
# Can anyone help with a quick query...
#
# I've seen the ASSERT macro defined as:
#
#
# #define ASSERT(f) \
# do { \
# if (!(f) && assertFailedOnL ine (THIS_FILE, __LINE__)) \
# FatalExit (0); \
# } while (0) \
#
#
# When I comple this in debug mode the compiler warns "conditiona l
# expression is constant", because of the while (0). Why is the ASSERT
# macro defined this way? The loop only runs once so why not get rid of
# the do..while and use:
#
#
# #define ASSERT(f) \
# if (!(f) && assertFailedOnL ine (THIS_FILE, __LINE__)) \
# FatalExit (0); \

Why not try something like
if (p)
ASSERT(q)
else
s;
and see what happens.

You can prevent this by bracing
#define ASSERT(f) {\
if (!(f) && assertFailedOnL ine (THIS_FILE, __LINE__)) \
FatalExit (0); }
but now you have to remember that although ASSERT(q) looks like a statement,
if you put a ';' after it
if (p)
ASSERT(q);
else
s;
it breaks unexpectedly.

Now try the original definition of ASSERT in the above.

# This also gets rid of the compiler warning.

So does the right -w option.

--
Derk Gwen http://derkgwen.250free.com/html/index.html
God's a skeeball fanatic.

[ANNE Alexis]

"Martin" <mr*****@totali se.co.uk> a écrit dans le message de news:
cb************* *************@p osting.google.c om...

Can anyone help with a quick query...

I've seen the ASSERT macro defined as:
#define ASSERT(f) \
do { \
if (!(f) && assertFailedOnL ine (THIS_FILE, __LINE__)) \
FatalExit (0); \
} while (0) \
When I comple this in debug mode the compiler warns "conditiona l
expression is constant", because of the while (0). Why is the ASSERT
macro defined this way? The loop only runs once so why not get rid of
the do..while and use:
#define ASSERT(f) \
if (!(f) && assertFailedOnL ine (THIS_FILE, __LINE__)) \
FatalExit (0); \
This also gets rid of the compiler warning.

Is there any reason to use the first definition?

I don't know how it's call in english, so I try to explain it.
It because "effets de bord" tha are problem due to what we can find just
before an after the use of this macro.
In some cases, one part of the macro is included in something we don't want
to.

example:
# define ADD(A, B) A + B

ADD(1, 2) * 3 get after preprocessing: 1 + 2 * 3
or I'm sure you want: (1 + 2) * 3

so, we prefer to use:
#define ADD(A, B) ((A) + (B))

When you use function, you can use the do { blablabla } while (0) that is
the same thing, addapted to function.
I hope you'll understand however my bad english.

[Mark Gordon]

On 15 Nov 2003 03:34:20 -0800
mr*****@totalis e.co.uk (Martin) wrote:

Can anyone help with a quick query...

I've seen the ASSERT macro defined as:
#define ASSERT(f) \
do { \
if (!(f) && assertFailedOnL ine (THIS_FILE, __LINE__)) \
FatalExit (0); \
} while (0) \
When I comple this in debug mode the compiler warns "conditiona l
expression is constant", because of the while (0). Why is the ASSERT
macro defined this way? The loop only runs once so why not get rid of
the do..while and use:
#define ASSERT(f) \
if (!(f) && assertFailedOnL ine (THIS_FILE, __LINE__)) \
FatalExit (0); \
This also gets rid of the compiler warning.

Is there any reason to use the first definition?

if (x)
for (y=x; y>0 && a[x]!=TARGET]; y--)
ASSERT(a[x]==BAD);
else
y=-1;

Given your definition (minus spurious \) this expands to
if (x)
for (y=x; y>0 && a[x]!=TARGET]; y--)
if (!(a[x]==BAD) && assertFailedOnL ine (THIS_FILE, __LINE__))
FatalExit (0);;
else
y=-1;

Note the two semicolons after FatalExis(0) which makes the else invalid.
Get rid of the spurious semicolon you get
if (x)
for (y=x; y>0 && a[x]!=TARGET]; y--)
if (!(a[x]==BAD) && assertFailedOnL ine (THIS_FILE, __LINE__))
FatalExit (0);
else
y=-1;

which makes the else associate with the if from the assert macro. Given
the original definition you get

if (x)
for (y=x; y>0 && a[x]!=TARGET]; y--)
do { \
if (!(a[x]==BAD) && assertFailedOnL ine (THIS_FILE, __LINE__))
FatalExit (0);
} while (0);
else
y=-1;

which will behave as expected.

This is why you will see people using do { ... } while (0) in macros
when they want something that behaves like a function with a return type
of void. Also note the lack of a semicolon at the end of the macro
definition.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.

[Nudge]

ANNE Alexis wrote:

I don't know how it's call in english, so I try to explain it. It
because "effets de bord" tha are problem due to what we can find
just before an after the use of this macro.

Hello petit Jean Kevin de la porte d'Ivry :-)

"Effets de bord" is the (unfortunate) French translation for "side
effects". It should, instead, have been translated to "effets
secondaires".

[pete]

Martin wrote:

Can anyone help with a quick query...

I've seen the ASSERT macro defined as:

#define ASSERT(f) \
do { \
if (!(f) && assertFailedOnL ine (THIS_FILE, __LINE__)) \
FatalExit (0); \
} while (0) \ #define ASSERT(f) \
if (!(f) && assertFailedOnL ine (THIS_FILE, __LINE__)) \
FatalExit (0); \

If you place a backslash as the last character
in the last line of a macro, then,
it is no longer the last line of the macro.

--
pete

[James Hu]

On 2003-11-15, Martin <mr*****@totali se.co.uk> wrote:

#define ASSERT(f) \
do { \
if (!(f) && assertFailedOnL ine (THIS_FILE, __LINE__)) \
FatalExit (0); \
} while (0) \
vs...
#define ASSERT(f) \
if (!(f) && assertFailedOnL ine (THIS_FILE, __LINE__)) \
FatalExit (0); \

Is there any reason to use the first definition?

This is a comp.lang.c FAQ. Please read the answer to question 10.4 of
the C-faq.

http://www.eskimo.com/~scs/C-faq/top.html

-- James
--
The C-faq. Use for rubbing, massaging, and as an external stimulant.

[Christian Bau]

In article <cb************ **************@ posting.google. com>,
mr*****@totalis e.co.uk (Martin) wrote:

Can anyone help with a quick query...

I've seen the ASSERT macro defined as:
#define ASSERT(f) \
do { \
if (!(f) && assertFailedOnL ine (THIS_FILE, __LINE__)) \
FatalExit (0); \
} while (0) \
When I comple this in debug mode the compiler warns "conditiona l
expression is constant", because of the while (0). Why is the ASSERT
macro defined this way? The loop only runs once so why not get rid of
the do..while and use:
#define ASSERT(f) \
if (!(f) && assertFailedOnL ine (THIS_FILE, __LINE__)) \
FatalExit (0); \
This also gets rid of the compiler warning.

Is there any reason to use the first definition?

Try compiling this:

if (x >= 0)
ASSERT (x <= 10);
else
ASSERT (x >= -10);

[Richard Heathfield]

Christian Bau wrote:

In article <cb************ **************@ posting.google. com>,
mr*****@totalis e.co.uk (Martin) wrote:

Can anyone help with a quick query...

I've seen the ASSERT macro defined as:
#define ASSERT(f) \
do { \
if (!(f) && assertFailedOnL ine (THIS_FILE, __LINE__)) \
FatalExit (0); \
} while (0) \
When I comple this in debug mode the compiler warns "conditiona l
expression is constant", because of the while (0). Why is the ASSERT
macro defined this way? The loop only runs once so why not get rid of
the do..while and use:
#define ASSERT(f) \
if (!(f) && assertFailedOnL ine (THIS_FILE, __LINE__)) \
FatalExit (0); \
This also gets rid of the compiler warning.

Is there any reason to use the first definition?

Try compiling this:

if (x >= 0)
ASSERT (x <= 10);
else
ASSERT (x >= -10);

Another excellent argument for using { } every time.

#define ASSERT(f) \
if (!(f) && assertFailedOnL ine(__FILE__, __LINE__)) \
FatalExit (0);

if(x >= 0)
{
ASSERT(x <= 10);
}
else
{
ASSERT(x >= -10);
}

....works just fine without the do/while(0) silliness.

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Christopher Benson-Manica]

Richard Heathfield <do******@addre ss.co.uk.invali d> spoke thus:

...works just fine without the do/while(0) silliness.

Does that mean that the do/while(0) bit is merely an obfuscating
device?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.