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

mr*****@totalise.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) && assertFailedOnLine (THIS_FILE, __LINE__)) \
# FatalExit (0); \
# } while (0) \
#
#
# When I comple this in debug mode the compiler warns "conditional
# 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) && assertFailedOnLine (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) && assertFailedOnLine (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.

"Martin" <mr*****@totalise.co.uk> a écrit dans le message de news:
cb**************************@posting.google.com...

Can anyone help with a quick query...

I've seen the ASSERT macro defined as:
#define ASSERT(f) \
do { \
if (!(f) && assertFailedOnLine (THIS_FILE, __LINE__)) \
FatalExit (0); \
} while (0) \
When I comple this in debug mode the compiler warns "conditional
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) && assertFailedOnLine (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.

On 15 Nov 2003 03:34:20 -0800
mr*****@totalise.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) && assertFailedOnLine (THIS_FILE, __LINE__)) \
FatalExit (0); \
} while (0) \
When I comple this in debug mode the compiler warns "conditional
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) && assertFailedOnLine (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) && assertFailedOnLine (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) && assertFailedOnLine (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) && assertFailedOnLine (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.

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".

Martin wrote:

Can anyone help with a quick query...

I've seen the ASSERT macro defined as:

#define ASSERT(f) \
do { \
if (!(f) && assertFailedOnLine (THIS_FILE, __LINE__)) \
FatalExit (0); \
} while (0) \ #define ASSERT(f) \
if (!(f) && assertFailedOnLine (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

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

#define ASSERT(f) \
do { \
if (!(f) && assertFailedOnLine (THIS_FILE, __LINE__)) \
FatalExit (0); \
} while (0) \
vs...
#define ASSERT(f) \
if (!(f) && assertFailedOnLine (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.

In article <cb**************************@posting.google.com >,
mr*****@totalise.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) && assertFailedOnLine (THIS_FILE, __LINE__)) \
FatalExit (0); \
} while (0) \
When I comple this in debug mode the compiler warns "conditional
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) && assertFailedOnLine (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);

Christian Bau wrote:

In article <cb**************************@posting.google.com >,
mr*****@totalise.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) && assertFailedOnLine (THIS_FILE, __LINE__)) \
FatalExit (0); \
} while (0) \
When I comple this in debug mode the compiler warns "conditional
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) && assertFailedOnLine (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) && assertFailedOnLine(__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.powernet.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

Richard Heathfield <do******@address.co.uk.invalid> 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)cyberspace.org | don't, I need to know. Flames welcome.

Christopher Benson-Manica wrote:

Richard Heathfield <do******@address.co.uk.invalid> spoke thus:

[

#define ASSERT(f) \
if (!(f) && assertFailedOnLine(__FILE__, __LINE__)) \
FatalExit (0); ] ...works just fine without the do/while(0) silliness.

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

No. It is a device to increase the robustness of the code. Without
the do/while wrapper the macro will work in certain circumstances, but
have silently incorrect behaviour if used as the body of a braceless
"if" statement (which has a matching "else"). In this particular case
the macro /can/ be written to have the correct behaviour without
do/while:

#define ASSERT(f) \
(void)((!f || assertFailedOnLine(__FILE__, __LINE__)) && (FatalExit(0), 0))

but if the macro must expand to multiple /statements/ then the
do/while trick (or something similar) is needed for the macro to have
the correct behaviour.
Jeremy.

Jeremy Yallop wrote:

#define ASSERT(f) \
(void)((!f || assertFailedOnLine(__FILE__, __LINE__)) && (FatalExit(0), 0))

`!(f)', not `!f'.

--
Hallvard

Hallvard B Furuseth wrote:

Jeremy Yallop wrote:

#define ASSERT(f) \
(void)((!f || assertFailedOnLine(__FILE__, __LINE__)) && (FatalExit(0), 0))

`!(f)', not `!f'.

Thanks, good catch.

Jeremy.

Christian Bau wrote:

In article <bp**********@sparta.btinternet.com>,
Richard Heathfield <do******@address.co.uk.invalid> wrote:

Christopher Benson-Manica wrote:

> Richard Heathfield <do******@address.co.uk.invalid> 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?

If you write:

if(foo)
bar();

then no, it is not.

If you write:

if(foo)
{
bar();
}

then yes, it is.

If you think that removing the braces in

if(foo)
{
bar();
}

shouldn't cause any problems, then it isn't.

But if you aren't ever going to do that, because you'd rather gnaw off your
own leg than use a single-statement if, then it is.

Over to you, Christian. :-)

--
Richard Heathfield : bi****@eton.powernet.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

Richard Heathfield <do******@address.co.uk.invalid> wrote:

Christian Bau wrote:

In article <bp**********@sparta.btinternet.com>,
Richard Heathfield <do******@address.co.uk.invalid> wrote:

Christopher Benson-Manica wrote:

> Richard Heathfield <do******@address.co.uk.invalid> spoke thus:
>

If you write:

if(foo)
{
bar();
}

then yes, it is.

If you think that removing the braces in

if(foo)
{
bar();
}

shouldn't cause any problems, then it isn't.

But if you aren't ever going to do that, because you'd rather gnaw off your
own leg than use a single-statement if, then it is.

But if the person maintaining your code is not in the same
state of mind?

Alex

Alex wrote:

Richard Heathfield <do******@address.co.uk.invalid> wrote:

Christian Bau wrote:

In article <bp**********@sparta.btinternet.com>,
Richard Heathfield <do******@address.co.uk.invalid> wrote:

Christopher Benson-Manica wrote:

> Richard Heathfield <do******@address.co.uk.invalid> spoke thus:
>

If you write:

if(foo)
{
bar();
}

then yes, it is.

If you think that removing the braces in

if(foo)
{
bar();
}

shouldn't cause any problems, then it isn't.

But if you aren't ever going to do that, because you'd rather gnaw off
your own leg than use a single-statement if, then it is.

But if the person maintaining your code is not in the same
state of mind?

Then I'd be beside myself. :-)

Seriously, it's a reasonable point, but in my defence[1] I generally do my
level best to get the coding standards at a client site changed to mandate
compound statements if they don't already do so. I've had some degree of
success with this. :-)

--
Richard Heathfield : bi****@eton.powernet.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

[snips]

On Thu, 20 Nov 2003 18:18:33 +0000, Richard Heathfield wrote:

Seriously, it's a reasonable point, but in my defence[1] I generally do my
level best to get the coding standards at a client site changed to mandate
compound statements if they don't already do so. I've had some degree of
success with this. :-)

As in:

if ( x )
{
y();
}

This is, IMO, bad. It clutters code with unnecessary crud. If it helps
because y might be some mucked-up macro that does weird things with block
levels or other sorts of nastiness, I'd tend to focus on the problem -
the macro - rather than this sort of approach.

Then again, I'd tend to try to disallow macros beyond the most trivial in
the first place - use a function, not a macro, if it needs to "do things".

Kelsey Bjarnason wrote:

[snips]

On Thu, 20 Nov 2003 18:18:33 +0000, Richard Heathfield wrote:

I generally do
my level best to get the coding standards at a client site changed to
mandate compound statements if they don't already do so. I've had some
degree of success with this. :-)
As in:

if ( x )
{
y();
}

Yes, precisely. Well, not quite as much whitespace. I'd prefer:

if(0 != x)
{
y();
}

This is, IMO, bad.
That doesn't surprise me, but I must disagree with you.
It clutters code with unnecessary crud.
That's a negative description. Here's a positive one to balance: it
emphasises the logical structure of the code.
If it helps
because y might be some mucked-up macro that does weird things with block
levels or other sorts of nastiness, I'd tend to focus on the problem -
the macro - rather than this sort of approach.
No, the macro isn't the problem. People are the problem. They /will/ keep
turning this:

if(w != x)
y();

into this:

if(w != x)
y();
z();

and then wondering why z() is called more often than they expected. (Utter
foolishness, I know.)

No, I'm perfectly happy with my bracing style, thanks - even if you disagree
with it.
Then again, I'd tend to try to disallow macros beyond the most trivial in
the first place - use a function, not a macro, if it needs to "do things".

There are certain rather obvious uses for macros. (Bit-twiddling is one.
Wrapping __FILE__ and __LINE__ is another.)
--
Richard Heathfield : bi****@eton.powernet.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

On Sun, 23 Nov 2003 06:42:58 +0000, Richard Heathfield wrote:

No, the macro isn't the problem. People are the problem. They /will/ keep
turning this:

if(w != x)
y();

into this:

if(w != x)
y();
z();

and then wondering why z() is called more often than they expected. (Utter
foolishness, I know.)

No, I'm perfectly happy with my bracing style, thanks - even if you disagree
with it.

I'm going to offer what may be an odd opinion. I don't follow your style
Richard; I like to use single statements without braces after if(). I have
never seen a single case in which a programmer actually had any problem
with this style. But I would support mandatory bracing in a coding
standards document because I think it makes the code easier to read when
more than one person is working on it.

Richard Heathfield <do******@address.co.uk.invalid> writes:

Yes, precisely. Well, not quite as much whitespace. I'd prefer:

if(0 != x)
{
y();
}
<SNIP>
No, the macro isn't the problem. People are the problem. They /will/ keep
turning this:

if(w != x)
y();

into this:

if(w != x)
y();
z();

and then wondering why z() is called more often than they expected. (Utter
foolishness, I know.)

What is wrong with simply

if(x) y();

???

--

John Devereux

John Devereux wrote:

What is wrong with simply

if(x) y();

???

Syntactically, nothing. In practice, there are two reasons why I don't do
this.

Firstly, when I'm stepping through code with one of those new-fangled
debuggers, it's much easier to see whether y() is called if it's on a
separate line.

Secondly (and this applies equally to the multi-line version of the same
code), Murphy's Law states quite clearly that, if I use a single-statement
if() now, I will inevitably, and probably at some point in the very near
future, think of something else that needs to be done in the same block, so
I might as well make it a compound statement right now.

--
Richard Heathfield : bi****@eton.powernet.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

Richard Heathfield <do******@address.co.uk.invalid> writes:

John Devereux wrote:

What is wrong with simply

if(x) y();

???
Syntactically, nothing. In practice, there are two reasons why I don't do
this.

Firstly, when I'm stepping through code with one of those new-fangled
debuggers, it's much easier to see whether y() is called if it's on a
separate line.

Yes, that's true. Similarly, I suppose your form makes it easier to
locate the offending line when you get a compiler diagnostic.
Secondly (and this applies equally to the multi-line version of the same
code), Murphy's Law states quite clearly that, if I use a single-statement
if() now, I will inevitably, and probably at some point in the very near
future, think of something else that needs to be done in the same block, so
I might as well make it a compound statement right now.

No. Never do today what can be put off until tomorrow :)
--

John Devereux

Richard Heathfield wrote:

.... snip ...
No, the macro isn't the problem. People are the problem. They
/will/ keep turning this:

if(w != x)
y();

into this:

if(w != x)
y();
z();

and then wondering why z() is called more often than they expected.
(Utter foolishness, I know.)

Which is why my compromise, not rigorously adhered to, is:

if (w != x) y();
vs
if (w != x) {
y();
z();
}

This removes the temptation to squeeze in a line somewhere. It
also does not exacerbate the newline shortage.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

CBFalconer wrote:

Richard Heathfield wrote:

... snip ...

No, the macro isn't the problem. People are the problem. They
/will/ keep turning this:

if(w != x)
y();

into this:

if(w != x)
y();
z();

and then wondering why z() is called more often than they expected.
(Utter foolishness, I know.)

Which is why my compromise, not rigorously adhered to, is:

if (w != x) y();
vs
if (w != x) {
y();
z();
}

This removes the temptation to squeeze in a line somewhere. It
also does not exacerbate the newline shortage.

No shortage here in the UK. In the interests of cross-pond amity, I present
you with a newline generator:

#include <stdio.h>
{
int i = 0;
while(i++ < 1000)
{
puts("\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n");
}
return 0;
}

You can redirect to a file, of course. If you use them all up, just run it
again.

No charge. God Bless America.

--
Richard Heathfield : bi****@eton.powernet.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

On Sun, 23 Nov 2003 02:34:01 -0500, Sheldon Simms
<sh**********@yahoo.com> wrote:

I have
never seen a single case in which a programmer actually had any problem
with this style

I have. I don't know how often it happens, because I only see those
cases where the bug doesn't become obvious immediately and I have to
fix it.

--
Al Balmer
Balmer Consulting
re************************@att.net

In <vf**********@devereux.me.uk> John Devereux <jd*@devereux.me.uk> writes:

Richard Heathfield <do******@address.co.uk.invalid> writes:

John Devereux wrote:

What is wrong with simply

if(x) y();

???

Syntactically, nothing. In practice, there are two reasons why I don't do
this.

Firstly, when I'm stepping through code with one of those new-fangled
debuggers, it's much easier to see whether y() is called if it's on a
separate line.

Yes, that's true. Similarly, I suppose your form makes it easier to
locate the offending line when you get a compiler diagnostic.

If this is an issue at all (not everybody is a debugger junkie), there is
a simpler solution:

if (x)
y();

i.e. exactly the way you'd do it if x were a fairly long expression and/or
the y() function had a lot of parameters.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

Richard Heathfield <do******@address.co.uk.invalid> spoke thus:

No shortage here in the UK. In the interests of cross-pond amity, I present
you with a newline generator: (snipped)

You do seem to be short on semicolons however, because apparently you
didn't have enough to both write proper code and supply a winky-face
to indicate that the post was tongue-in-cheek. I'd give you a few,
but unfortunately I don't even have one to winky-face this post, never
mind yours. It seems, then, that we will sound much terser than we
really are, at least until China begins exporting cheap semicolons.

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

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:

Richard Heathfield <do******@address.co.uk.invalid> spoke thus:

No shortage here in the UK. In the interests of cross-pond amity, I present
you with a newline generator:

(snipped)

<unsnipped>
#include <stdio.h>
{
int i = 0;
while(i++ < 1000)
{
puts("\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n");
}
return 0;
}
You do seem to be short on semicolons however, because apparently you
didn't have enough to both write proper code and supply a winky-face
to indicate that the post was tongue-in-cheek.
As it turns out Richard isn't short on semicolons but on
'int main(void)'s. I can offer him some of my spare ones:

int main(void) int main(void) int main(void) int main(void)
int main(void) int main(void) int main(void) int main(void)

BTW: I still have a whole lot of 'void main(void)'s in a box
in my cellar, left over from my first attempts in writing C
programs; is anybody interested? Free of charge, delivery via
email...
I'd give you a few,
but unfortunately I don't even have one to winky-face this post, never
mind yours. It seems, then, that we will sound much terser than we
really are, at least until China begins exporting cheap semicolons.

Coincidentally I just received a box of brand new premium semicolons
today; here you go:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;

If you need more, just email me. ;-)
--
Irrwahn
(ir*******@freenet.de)

Irrwahn Grausewitz <ir*******@freenet.de> spoke thus:

Coincidentally I just received a box of brand new premium semicolons
today; here you go: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;

Great, thanks. My winky faces will look stupdendous now ;)

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

On Wed, 26 Nov 2003 15:41:18 +0000 (UTC), Christopher Benson-Manica
<at***@nospam.cyberspace.org> wrote:

Richard Heathfield <do******@address.co.uk.invalid> spoke thus:

No shortage here in the UK. In the interests of cross-pond amity, I present
you with a newline generator:

(snipped)

You do seem to be short on semicolons however, because apparently you
didn't have enough to both write proper code and supply a winky-face
to indicate that the post was tongue-in-cheek.

I didn't need a "winky-face" to categorize that post ;-)

--
Al Balmer
Balmer Consulting
re************************@att.net

On Wed, 26 Nov 2003 18:18:23 +0100, Irrwahn Grausewitz
<ir*******@freenet.de> wrote:

As it turns out Richard isn't short on semicolons but on
'int main(void)'s. I can offer him some of my spare ones:

I assumed it was a function, to be called whenever more newlines are
needed. Although you could argue that newlines are an end in
themselves.

--
Al Balmer
Balmer Consulting
re************************@att.net

Alan Balmer <al******@att.net> wrote:

On Wed, 26 Nov 2003 18:18:23 +0100, Irrwahn Grausewitz
<ir*******@freenet.de> wrote:

As it turns out Richard isn't short on semicolons but on
'int main(void)'s. I can offer him some of my spare ones:
I assumed it was a function, to be called whenever more newlines are
needed.

If so, he's short on funcion names. ;-)
Although you could argue that newlines are an end in
themselves.

:)
--
Irrwahn
(ir*******@freenet.de)

Irrwahn Grausewitz wrote:

Alan Balmer <al******@att.net> wrote:

On Wed, 26 Nov 2003 18:18:23 +0100, Irrwahn Grausewitz
<ir*******@freenet.de> wrote:

>As it turns out Richard isn't short on semicolons but on
>'int main(void)'s. I can offer him some of my spare ones:

I assumed it was a function, to be called whenever more newlines are
needed.

If so, he's short on funcion names. ;-)

^^^^^^^
tttttttt
tttttttt
tttttttt
tttttttt
tttttttttttttttttttttttttttttttttttttttt
tttttttttttttttttttttttttttttttttttttttt
tttttttttttttttttttttttttttttttttttttttt
tttttttttttttttttttttttttttttttttttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt tttttttt
tttttttt tttttttt
ttttttttttttttttttt
ttttttttttttttttt
tttttttttttttt
tttttttttt
You seemed o be a bi shor of he le er ' '. You are mos welcome o some
of mine.

--
Richard Heathfield : bi****@eton.powernet.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

Richard Heathfield <in*****@address.co.uk.invalid> wrote:

Irrwahn Grausewitz wrote:

<snip>

If so, he's short on funcion names. ;-)

^^^^^^^
tttttttt
tttttttt
tttttttt
tttttttt
tttttttttttttttttttttttttttttttttttttttt
tttttttttttttttttttttttttttttttttttttttt
tttttttttttttttttttttttttttttttttttttttt
tttttttttttttttttttttttttttttttttttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt tttttttt
tttttttt tttttttt
ttttttttttttttttttt
ttttttttttttttttt
tttttttttttttt
t ttt
You seemed o be a bi shor of he le er ' '. You are mos welcome o some
of mine.

Ahh, that's better now, thanks a lot. :D
--
Irrwahn
(ir*******@freenet.de)

On Sun, 23 Nov 2003 19:05:41 +0000 (UTC), Richard Heathfield
<do******@address.co.uk.invalid> wrote:

CBFalconer wrote: <snip>

This removes the temptation to squeeze in a line somewhere. It
also does not exacerbate the newline shortage.

No shortage here in the UK. In the interests of cross-pond amity, I present
you with a newline generator:

#include <stdio.h>
{
int i = 0;
while(i++ < 1000)
{
puts("\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n");
}
return 0;
}

IRRTYWanted an int main(void) in there.
You can redirect to a file, of course. If you use them all up, just run it
again.

No charge. God Bless America.

<PHB> I tried (with that correction) and after several thousand runs
my battery ran down. Please email me some more electricity. </>

- David.Thompson1 at worldnet.att.net

If you[*] feel compelled to keep this inane thread alive, have at least
the minimal decency to insert an [OT] tag in the subject line.
___
[*] By "you" I'm not referring to Richard Heathfield *only*.

Dan

P.S. Deliberately top posting because this is one of the cases where top
posting is appropriate. While keeping RH's nonsense included in my
post, to provide the necessary context, there is no point in
forcing everybody to scroll through it in order to find my text.

In <3f******@news2.power.net.uk> Richard Heathfield <in*****@address.co.uk.invalid> writes:

Irrwahn Grausewitz wrote:

Alan Balmer <al******@att.net> wrote:

On Wed, 26 Nov 2003 18:18:23 +0100, Irrwahn Grausewitz
<ir*******@freenet.de> wrote:

>As it turns out Richard isn't short on semicolons but on
>'int main(void)'s. I can offer him some of my spare ones:

I assumed it was a function, to be called whenever more newlines are
needed.

If so, he's short on funcion names. ;-)

^^^^^^^
tttttttt
tttttttt
tttttttt
tttttttt
tttttttttttttttttttttttttttttttttttttttt
tttttttttttttttttttttttttttttttttttttttt
tttttttttttttttttttttttttttttttttttttttt
tttttttttttttttttttttttttttttttttttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt
tttttttt tttttttt
tttttttt tttttttt
ttttttttttttttttttt
ttttttttttttttttt
tttttttttttttt
tttttttttt
You seemed o be a bi shor of he le er ' '. You are mos welcome o some
of mine.

--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

Dan Pop wrote:

If you[*] feel compelled to keep this inane thread alive, have at least
the minimal decency to insert an [OT] tag in the subject line.

Indeed. But I think we're done now.

<snip>

--
Richard Heathfield : bi****@eton.powernet.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