While(1) or for(;;) for infinite loops?

[Antoninus Twink]

Somehow I don't think RH would ever write such an infinite loop, as
that would imply having to escape from it using break, return, goto or
exit() instead.

More importantly, it would imply having stdbool.h available, and
Heathfield's pride will never let him accept a C99 feature in his
sophomoric coding "style".

 

[Antoninus Twink]

It's hard to copy something you haven't seen.

Sure, Dicky.

I think we all remember Han's damning exposure of the fake killfiling
behavior perpetrated by you, Thompson and the rest of your trolling
unit.

If he's actually said something sensible for a change, however, I
suppose we should celebrate the novelty of the event.

You may well celebrate, but it makes me extremely uneasy to learn that
there is something (albeit a minor stylistic question) on which I agree
with a man who shows such exceptionally poor taste on most other
matters.

 

[Eric Sosman]

[...]
But that brings up an interesting point: some languages seem happy to
evolve and to embrace new syntax, but some, like C, don't.

For some reason (my aging eyesight, perhaps), I'm having
trouble finding function prototype syntax described in my
copy of K&R Classic. Would you mind telling me which pages
cover it?

It would be nice if you'd also point me to the description
of `...' variable-argument syntax.

Thanks!

 

[Antti-Juhani Kaijanaho]

Oh goodie, just what we need: another if/else ambiguity!

do
do { }
while (condition); /* oops, goes with the inner do. right? */

Just require a semicolon after the block if the while part is missing.

 

[Adrian Petrescu]

[...]
But that brings up an interesting point: some languages seem happy to
evolve and to embrace new syntax, but some, like C, don't.

For some reason (my aging eyesight, perhaps), I'm having
trouble finding function prototype syntax described in my copy of K&R
Classic. Would you mind telling me which pages cover it?

It would be nice if you'd also point me to the description
of `...' variable-argument syntax.

Thanks!

If, as it seems, you are sarcastically implying that two urgently-needed
additions to the language in the 32 years since the publication of K&R
qualify C as "happy to evolve and embrace new syntax", there is more than
just your eyesight that is aging

-Adrian

 

[Eric Sosman]

[...]
But that brings up an interesting point: some languages seem happy to
evolve and to embrace new syntax, but some, like C, don't.

For some reason (my aging eyesight, perhaps), I'm having
trouble finding function prototype syntax described in my copy of K&R
Classic. Would you mind telling me which pages cover it?

It would be nice if you'd also point me to the description
of `...' variable-argument syntax.

Thanks!

If, as it seems, you are sarcastically implying that two urgently-needed
additions to the language in the 32 years since the publication of K&R
qualify C as "happy to evolve and embrace new syntax", there is more than
just your eyesight that is aging

My eyesight has a tendency to age at about the same rate
the rest of me does.

However, my point stands: bartc's observation is based on
an obvious falsehood. He also fails to consider that the
inventor of C (and the inventors of its predecessors) already
had knowledge of FORTRAN and COBOL and ALGOL and a sheaf of
other, older languages, and from the experience gained they
were able to get a "head start." FORTRAN/Fortran found it
necessary to add constructs that C already had; should C
respond by adding yet more constructs just so it can have
bragging rights? Pfui.

Maybe it's time to revive the COMEFROM statement.

 

[Adrian Petrescu]

However, my point stands: bartc's observation is based on
an obvious falsehood. He also fails to consider that the inventor of C
(and the inventors of its predecessors) already had knowledge of FORTRAN
and COBOL and ALGOL and a sheaf of other, older languages, and from the
experience gained they were able to get a "head start." FORTRAN/Fortran
found it necessary to add constructs that C already had; should C
respond by adding yet more constructs just so it can have bragging
rights? Pfui.

Actually, in spirit I agree completely with you I think C's
immutability is one of its strong points; no other language is so solidly
compatible. I was just amused that you were implying that the few
additions that _have_ been made since K&R qualified it as the 'evolving'
and 'embracing' language that bartc seemed to be wishing for.

I guess we were both just being a little sarcastic No hard feelings.

Cheers,
Adrian

 

[Eric Sosman]

Actually, in spirit I agree completely with you I think C's
immutability is one of its strong points; no other language is so solidly
compatible. I was just amused that you were implying that the few
additions that _have_ been made since K&R qualified it as the 'evolving'
and 'embracing' language that bartc seemed to be wishing for.

There have, of course, been many other changes to C. But
he specified "new syntax," and I didn't want to get into a silly
debate about whether new keywords (void, const, ...) and new
combinations (long long, long double) constituted "new syntax" or
just decorations to existing syntax. So I pointed out two changes
that are indisputably syntactic, beyond quibble.

I guess we were both just being a little sarcastic No hard feelings.

My sensayuma ages along with my eyesight ...

 

[Eric Sosman]

I would normally avoid it, yes. I have on occasion written infinite
loops (using for(;), but only (IIRC) when the loop truly was
infinite within the terms of the program itself - i.e. the program
was not self-terminating. (Clearly it could be killed externally,
either via the OS or via a power cycle.) I don't often write such
programs in C, however.

Haven't you been running a timing test on an infinite
loop for the past few years? Any results yet?

 

[Michael Tsang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I assume this has come up before but I am getting nowhere with searches.

To make an infinite loop, while(1) tends to generate lint/compiler
warnings, for(; does not.

Other than personal preference, are there any other technical reasons to
pick one over the other?

I will stipulate for the argument that performance is identical.

I normally prefer while(true) because it's the most straight forward and
everyone knows it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksbwUgACgkQG6NzcAXitM+3GQCdHlJ6okASx172MOop/QBBsv9X
paUAoIsdnr6G1OLLcthGZtwTfZ51dRvD
=JOKN
-----END PGP SIGNATURE-----

 

[Flash Gordon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I normally prefer while(true) because it's the most straight forward and
everyone knows it.

I'm not bothered by either. I always considered for(; to be obvious,
there is no termination condition so no termination. I consider while(1)
or while(true) to be obvious. I also consider "REPEAT UNTIL false" to be
obvious. I tend to use
for (;
I would also have no problem with
for (initialisation; ; iteration)

 

[Kaz Kylheku]

Just require a semicolon after the block if the while part is missing.

Oh goodie! Just what we need, double semicolon!

do S ; /* semicolon required to denote infinite looping over S */

Now let S be the statement ``do { } while(condition); '' and we get:

do
do { }
while (condition);;

Oops!

You know, we should be developing a vaccine against the the semicolon
disease, not spreading it.

 

[Keith Thompson]

I normally prefer while(true) because it's the most straight forward and
everyone knows it.

In C90, the identifier "true" is undeclared unless you've defined
it yourself (or it's defined by some header you've #included).
In C99, it's undeclared unless you have "#include <stdbool.h>" or,
as in C90, you've defined it yourself (which could create a conflict
if you later add "#include <stdbool.h>").

I wouldn't hesitate to write "while (true)" if I've already caused
"true" to be defined for some other reason, but I wouldn't introduce
it just for that purpose, since "while (1)" is such a common and
well known idiom.

 

[bartc]

Oh goodie! Just what we need, double semicolon!

Yeah.

Of course this is a different double semicolon from the one in for (;

 

[Flash Gordon]

You can have only one infinite loop in a program.

You can have more than one, it's just you will only reach one of them on
any given run. There are even good reasons for doing this on occasion.

If there is some (non-external) condition that terminates the loop,
generally it should be in the condition that controls it. However this isn't
always easy to arrange. A break/ goto is better than messing about with a
flag which is introduced purely to avoid having a jump.

That's a matter of style/opinion. I've done things both ways.

 

[James]

You can have only one infinite loop in a program.

What happens if a single program is comprised of multiple forms of separate
execution that do different things?

 

[Nick Keighley]

If, as it seems, you are sarcastically implying that two urgently-needed
additions to the language in the 32 years since the publication of K&R
qualify C as "happy to evolve and embrace new syntax", there is more than
just your eyesight that is aging

My K&R II has a publication dat of 1988. So according to you K&R I
came out 32 years earlier in 1956. That makes it older than Fortran!

In what way was the ... syntax "urgent"?

 

[Nick Keighley]

there are lots of things in C that aren't obvious. No we ban ?: or
function pointers?

I try to follow that rule but C's for doesn't limit you that way.

Somehow I don't think RH would ever write such an infinite loop, as that
would imply having to escape from it using break, return, goto or exit()
instead.

Some embedded systems may run for ever, or at least never terminate by
programmatic (it's a word?) reasons.

 

[Keith Thompson]

My K&R II has a publication dat of 1988. So according to you K&R I
came out 32 years earlier in 1956. That makes it older than Fortran!

K&R1 was published, if I recall correctly, in 1978, 31 years ago. If
it was early in the year 32 years is a more accurate figure.

 

[Nick Keighley]

K&R1 was published, if I recall correctly, in 1978, 31 years ago.  If
it was early in the year 32 years is a more accurate figure.

my point was they didn't wait 31/32 years before adding new syntax.
They waited 10. And more new syntax was added in 1999.