programming style: while(TRUE), for(;;), ...?

[Felix Kater]

Hi,

in some cases like dynamic memory allocation I find it convenient to
(ab-)use for() or while() like this:
/* (allocate memory) */

for(;;){ /* alternatively: while(TRUE){ */

/* (other code) */

break;
}

/* (free memory) */
The reason to do that is to remind the programmer who might not be me
not to forget things (like freeing memory) when inserting code later,
keep the order of commands (don't free too early) etc.
Two questions:

Are there generally better ways to do that?

Are there reasons to prefer one of the two ways (for vs, while) ?
Felix

[Suman]

Felix Kater wrote:

Hi,

in some cases like dynamic memory allocation I find it convenient to
(ab-)use for() or while() like this:
/* (allocate memory) */

for(;;){ /* alternatively: while(TRUE){ */

/* (other code) */

break;
}

/* (free memory) */
The reason to do that is to remind the programmer who might not be me
not to forget things (like freeing memory) when inserting code later,
keep the order of commands (don't free too early) etc. If you put an infinite loop in between, then that piece of code
will never ever come to free memory part.Right? So prevention has
caused
a disease here.
Two questions:

Are there generally better ways to do that?

Are there reasons to prefer one of the two ways (for vs, while) ?

Do you mean to say whether I'd prefer murder to assasination?

[Lawrence Kirby]

On Tue, 05 Jul 2005 04:30:45 -0700, Suman wrote:

Felix Kater wrote:

Hi,

in some cases like dynamic memory allocation I find it convenient to
(ab-)use for() or while() like this:
/* (allocate memory) */

for(;;){ /* alternatively: while(TRUE){ */

/* (other code) */

break;
}

/* (free memory) */
The reason to do that is to remind the programmer who might not be me
not to forget things (like freeing memory) when inserting code later,
keep the order of commands (don't free too early) etc.
I'm not clear how the for() really helps here. Does it potentially use
break in multiple places to go to the cleanup code?

If you put an infinite loop in between, then that piece of code
will never ever come to free memory part.Right? So prevention has
caused
a disease here.
The break statement ensures it isn't infinite, unless the loop body
contains continue statements.

Two questions:

Are there generally better ways to do that?
There's always goto. :-)
Are there reasons to prefer one of the two ways (for vs, while) ?

for (;;) and while (1) are equivalent.
Do you mean to say whether I'd prefer murder to assasination?

Hopefully it won't come to either.

Lawrence

[Suman]

Lawrence Kirby wrote:

On Tue, 05 Jul 2005 04:30:45 -0700, Suman wrote:

Felix Kater wrote:

Hi,

in some cases like dynamic memory allocation I find it convenient to
(ab-)use for() or while() like this:
/* (allocate memory) */

for(;;){ /* alternatively: while(TRUE){ */

/* (other code) */

break;
}

/* (free memory) */
The reason to do that is to remind the programmer who might not be me
not to forget things (like freeing memory) when inserting code later,
keep the order of commands (don't free too early) etc.
I'm not clear how the for() really helps here. Does it potentially use
break in multiple places to go to the cleanup code?

If you put an infinite loop in between, then that piece of code
will never ever come to free memory part.Right? So prevention has
caused
a disease here.

The break statement ensures it isn't infinite, unless the loop body
contains continue statements.

Concur.

Two questions:

Are there generally better ways to do that?

do {
/*stuff*/
} while ( 0 );

Or wrap the code in for/while in a function, and call it with proper
arguments. That should be easier, if the constraints under which one
works, allows that.

[Felix Kater]

Lawrence Kirby <lk****@netactive.co.uk> wrote:

The reason to do that is to remind the programmer who might not be me
not to forget things (like freeing memory) when inserting code later,
keep the order of commands (don't free too early) etc.
I'm not clear how the for() really helps here. Does it potentially use
break in multiple places to go to the cleanup code?

Yes, the multiple break points/exits lead to the same cleanup code.

Second: The opened brace (often together with indentation or folding in
the editor) reminds you that your are programming on something like a
sub level which will end at some point and execute other (important)
code on the main level.

Are there generally better ways to do that?
There's always goto. :-)

Third: I also think of nested situations where gotos are of course hard
to control.

Fourth: I beleve that it is not always a good practise to source out
pieces of code into new functions when these functions are used only
once. Using the suggested practise (together with a editor which can do
folding) could be a good substitution for that.

Are there reasons to prefer one of the two ways (for vs, while) ?

for (;;) and while (1) are equivalent.

Ok. I'll ask in a compiler's news group to check wheater there are
differences.
Felix

[Alan J. McFarlane]

In article news:20******************************@gmx.net, Felix Kater
wrote:

Lawrence Kirby <lk****@netactive.co.uk> wrote:

[...]

Are there reasons to prefer one of the two ways (for vs, while) ?

for (;;) and while (1) are equivalent.

Ok. I'll ask in a compiler's news group to check wheater there are
differences.

Well one difference is that many compilers will warn about "while(1)",
with
e.g.
warning C4127: conditional expression is constant
Whereas, they don't warn about "for (;;)" (presumably because it's much
more obvious to the reader (and to the writer of the code too)).

I haven't found a 'quiet' equivalent though for "do{ ... }while(0)" (as
recommended in http://www.eskimo.com/~scs/C-faq/q10.4.html).
--
Alan J. McFarlane
http://www.alanjmcf.me.uk/
Please follow-up in the newsgroup for the benefit of all.

[Ben Bacarisse]

On Tue, 05 Jul 2005 13:09:39 +0200, Felix Kater wrote:

in some cases like dynamic memory allocation I find it convenient to
(ab-)use for() or while() like this: <examples snipped> Two questions:

Are there generally better ways to do that?

I would not say "better" but (if I understand what you are doing) there
are alternatives such as:

switch (0 /* anything */) {
default:
<stuff with breaks>
}

which reads as if it is doing "default stuff" with no danger of
actually looping.

--
Ben.

[Giorgos Keramidas]

Ben Bacarisse <be********@bsb.me.uk> writes:

On Tue, 05 Jul 2005 13:09:39 +0200, Felix Kater wrote:

in some cases like dynamic memory allocation I find it convenient to
(ab-)use for() or while() like this:

<examples snipped>

Two questions:

Are there generally better ways to do that?

I would not say "better" but (if I understand what you are doing) there
are alternatives such as:

switch (0 /* anything */) {
default:
<stuff with breaks>
}

which reads as if it is doing "default stuff" with no danger of
actually looping.

Why would this be better than using <stuff with breaks> without the
funny switch() construct though?

[Lawrence Kirby]

On Tue, 05 Jul 2005 17:54:41 +0300, Giorgos Keramidas wrote:

....

I would not say "better" but (if I understand what you are doing) there
are alternatives such as:

switch (0 /* anything */) {
default:
<stuff with breaks>
}

which reads as if it is doing "default stuff" with no danger of
actually looping.

Why would this be better than using <stuff with breaks> without the
funny switch() construct though?

Without the switch() construct break wouldn't work. Presumably the idea is
to create a common jump-out point for the enclosed code.

Lawrence

[Giorgos Keramidas]

Lawrence Kirby <lk****@netactive.co.uk> writes:

On Tue, 05 Jul 2005 17:54:41 +0300, Giorgos Keramidas wrote:

I would not say "better" but (if I understand what you are doing) there
are alternatives such as:

switch (0 /* anything */) {
default:
<stuff with breaks>
}

which reads as if it is doing "default stuff" with no danger of
actually looping.

Why would this be better than using <stuff with breaks> without the
funny switch() construct though?

Without the switch() construct break wouldn't work. Presumably the idea is
to create a common jump-out point for the enclosed code.

Ah. I still don't see why a simple "goto err;" would ugly, but that's I
guess dangerously close to the place where religious flamefests live.

Anyway, thanks for the clarification :-)

[Alan Balmer]

On Tue, 5 Jul 2005 14:17:29 +0200, Felix Kater <f.******@gmx.net>
wrote:

Fourth: I beleve that it is not always a good practise to source out
pieces of code into new functions when these functions are used only
once. Using the suggested practise (together with a editor which can do
folding) could be a good substitution for that.

Not always, perhaps, but often. Putting a cohesive piece of code in
its own function can enhance readability and understanding of the
code.

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

[Sensei]

Felix Kater wrote:

for(;;){ /* alternatively: while(TRUE){ */

/* (other code) */

break;
}

/* (free memory) */

I prefer something like this.

char continueFlag = 1;

while (continueFlag)
{
...
}

A better control, even with break & co.
The reason to do that is to remind the programmer who might not be me
not to forget things (like freeing memory) when inserting code later,
keep the order of commands (don't free too early) etc.
For THIS reason? Why?
Are there generally better ways to do that?

Are there reasons to prefer one of the two ways (for vs, while) ?

for(;;) == while(1)

Do what you like... it's more sugar than real matter...

[Malcolm]

"Felix Kater" <f.******@gmx.net> wrote

Are there reasons to prefer one of the two ways (for vs, while) ?

while(1) is marginally better. for(;;) is what I call compileable gibberish.
It means nothing outside the specific context of C, whilst quite a few other
languages allow a constant conditional.

while(TRUE) would be even better, except for one thing. It means that some
idiot has defined TRUE to the preprocessor. Why this is a terrible idea
later, for now let's just say that this is ANSI's job not yours.

However all loops must terminate eventually. You should endevaour to put the
condition in the while statement if at all possible. Remember do ... while
is also available if the condition is not avialble on loop entry.

[Christian Bau]

In article <20******************************@gmx.net>,
Felix Kater <f.******@gmx.net> wrote:

Hi,

in some cases like dynamic memory allocation I find it convenient to
(ab-)use for() or while() like this:
/* (allocate memory) */

for(;;){ /* alternatively: while(TRUE){ */

/* (other code) */

break;
}

/* (free memory) */
The reason to do that is to remind the programmer who might not be me
not to forget things (like freeing memory) when inserting code later,
keep the order of commands (don't free too early) etc.
Two questions:

Are there generally better ways to do that?

Are there reasons to prefer one of the two ways (for vs, while) ?

The best way to write a "goto" statement is to write a "goto" statement.

[Christian Bau]

In article <da**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>,
"Malcolm" <re*******@btinternet.com> wrote:

"Felix Kater" <f.******@gmx.net> wrote

Are there reasons to prefer one of the two ways (for vs, while) ?

while(1) is marginally better. for(;;) is what I call compileable gibberish.
It means nothing outside the specific context of C, whilst quite a few other
languages allow a constant conditional.

Since comp.lang.c _always_ operates in the specific context of C, there
is nothing wrong at all with for (;;).

[CBFalconer]

Alan Balmer wrote:

Felix Kater <f.******@gmx.net> wrote:

Fourth: I beleve that it is not always a good practise to source
out pieces of code into new functions when these functions are
used only once. Using the suggested practise (together with a
editor which can do folding) could be a good substitution for that.

Not always, perhaps, but often. Putting a cohesive piece of code
in its own function can enhance readability and understanding of
the code.

In addition you probably get all the efficiency of the muddied
source anyway. The OP did state that it was used once, so the
separated code should be declared static. A good optimizer may
very well inline it without being told, and for gcc and C99 you can
simply mark it as inline.

Write for clarity first. Diddle only if needed. Do not take the
word of the rule of seven in vain.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Mark]

"Malcolm" <re*******@btinternet.com> wrote in message
news:da**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com...

"Felix Kater" <f.******@gmx.net> wrote

Are there reasons to prefer one of the two ways (for vs, while) ?
while(1) is marginally better. for(;;) is what I call compileable
gibberish. It means nothing outside the specific context of C, whilst
quite a few other languages allow a constant conditional.

Neither is better, or worse than the other... 98% of the time, the inclusion
of either
is a clue that the original coder wasn't smart enough to realize (s)he could
easily
create a flag and use it to terminate the loop! In these instances you'll
frequently
find ten or more breaks out of the loop and three or four return statements
INSIDE
which often return without properly closing open file descriptors and/or
without
freeing dynamically allocated memory. That's normally not a problem though
as
these loops, albeit a few thousand lines long, are typically found in the
program's
only function which is appropriately named, but often incorrectly defined:
main().
while(TRUE) would be even better, except for one thing. It means that some
idiot has defined TRUE to the preprocessor. Why this is a terrible idea
later, for now let's just say that this is ANSI's job not yours. then why not:
while(EXIT_FAILURE)
or
while(! EXIT_SUCCESS)
I'll tell you why not... because it's stupid! :)
However all loops must terminate eventually. Umm, no... some may need to run indefinately (as long as the system is
powered)
and in these instances it wouldn't matter if the coder chose to use while(1)
or for(;;)
You should endevaour to put the condition in the while statement if at all
possible. Remember do ... while is also available if the condition is not
avialble on loop entry.

Agreed.

Mark

[Ben Bacarisse]

On Tue, 05 Jul 2005 20:52:17 +0300, Giorgos Keramidas wrote:

Lawrence Kirby <lk****@netactive.co.uk> writes:

On Tue, 05 Jul 2005 17:54:41 +0300, Giorgos Keramidas wrote:

I would not say "better" but (if I understand what you are doing) there
are alternatives such as:

switch (0 /* anything */) {
default:
<stuff with breaks>
}

which reads as if it is doing "default stuff" with no danger of
actually looping.

Why would this be better than using <stuff with breaks> without the
funny switch() construct though?
Without the switch() construct break wouldn't work. Presumably the idea is
to create a common jump-out point for the enclosed code.

Yes indeed. Thanks for the clarification.
Ah. I still don't see why a simple "goto err;" would ugly, but that's I
guess dangerously close to the place where religious flamefests live.

Quite. I just thought I'd throw in another way to get break to do
goto's dirty work!

--
Ben.

[Alan Balmer]

On Tue, 5 Jul 2005 21:46:28 +0000 (UTC), "Malcolm"
<re*******@btinternet.com> wrote:

"Felix Kater" <f.******@gmx.net> wrote

Are there reasons to prefer one of the two ways (for vs, while) ?
while(1) is marginally better. for(;;) is what I call compileable gibberish.
It means nothing outside the specific context of C, whilst quite a few other
languages allow a constant conditional.

Not many C programs will successfully compile as other languages
anyway ;-)

In fact, with the compilers I use, I prefer for(;;), because it
doesn't generate a warning.

Q. What is ";;"?

A. Ever.

Usage: for ever.

while(TRUE) would be even better, except for one thing. It means that some
idiot has defined TRUE to the preprocessor. Why this is a terrible idea
later, for now let's just say that this is ANSI's job not yours.

However all loops must terminate eventually. You should endevaour to put the
condition in the while statement if at all possible. Remember do ... while
is also available if the condition is not avialble on loop entry.

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

[Me]

> in some cases like dynamic memory allocation I find it convenient to

(ab-)use for() or while() like this:
/* (allocate memory) */

for(;;){ /* alternatively: while(TRUE){ */

/* (other code) */

break;
}

/* (free memory) */
The reason to do that is to remind the programmer who might not be me
not to forget things (like freeing memory) when inserting code later,
keep the order of commands (don't free too early) etc.
If I saw code like that I would wonder wtf you were smoking when you
wrote it. do { } while(0); is almost always the best way to express
creation of a new scope because it's a common idiom and the other
common way makes you wonder why there are random braces lying around in
the middle of your code. Unfortunately, the do { } while (0); steals
the ability of you to break; out of an outer loop but that doesn't
appear to be a concern for you.
Are there generally better ways to do that?

ret = error_state;

if ((foo = init1()) != sentinel_foo)
goto _err1;
if ((boo = init2()) != sentinel_boo)
goto _err2;
....
ret = non_error_state;
// fall through if you want to free stuff
// otherwise goto done; or return ret;

err2:
free2(boo);
err1:
free1(foo);
done:
return ret;

or alternatively you can initialize foo and boo to some sentinel state:

if (...)
goto err;
if (...)
goto err;
....
err:
if (boo == sentinel_boo)
free2(boo);
if (foo == sentinel_foo)
free1(foo);
return ret;

You can even get rid of the sentinel checks if free2 and free1 work
when you pass sentinels.

[CBFalconer]

Mark wrote:

.... snip ...
then why not:
while(EXIT_FAILURE)
or
while(! EXIT_SUCCESS)
I'll tell you why not... because it's stupid! :)

A better reason is that you have absolutely no idea what those
statements will do, because you don't know the values of those
macros.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Vit]

Why do all these tricks with the compiler?
Why not just

#define FORGET_ME_NOT

and

FORGET_ME_NOT {
code stuff
}

?

Vit
http://www.excelsior-usa.com

[Richard Bos]

CBFalconer <cb********@yahoo.com> wrote:

Mark wrote:

then why not:
while(EXIT_FAILURE)
or
while(! EXIT_SUCCESS)
I'll tell you why not... because it's stupid! :)

A better reason is that you have absolutely no idea what those
statements will do, because you don't know the values of those
macros.

Well, half. You don't know that EXIT_SUCCESS is zero, so you don't know
that the second loop will go on indefinitely; but you do know that the
first is an unending loop, because EXIT_FAILURE cannot possibly compare
equal to 0 (since if it were, exit(EXIT_FAILURE) and exit(0) would be
identical).

Richard

[Asbjørn Sæbø]

Felix Kater <f.******@gmx.net> writes:

Lawrence Kirby <lk****@netactive.co.uk> wrote:

[...]
Second: The opened brace (often together with indentation or folding in
the editor) reminds you that your are programming on something like a
sub level which will end at some point and execute other (important)
code on the main level.

Can't you use just the braces (without the for/while) to achieve an
indented compound statement? Like this?

#include <stdio.h>

int main ()
{
printf("Numbers:\n");

{
/* Here comes a group of related statements, treat them as a unit */
printf("One\n");
printf("Two\n");
printf("Three\n");
}

/* And this is something you do afterwards */
return 0;
}
Asbj.S.

--
Asbjørn Sæbø, post.doc.
Centre for Quantifiable Quality of Service in Communication Systems
Norwegian University of Science and Technology
<URL: http://www.q2s.ntnu.no/ >

[Lawrence Kirby]

On Tue, 05 Jul 2005 20:10:40 -0700, Vit wrote:

Why do all these tricks with the compiler?
Why not just

#define FORGET_ME_NOT

and

FORGET_ME_NOT {
code stuff
}

This doesn't provide a simple way to jump to the point after the end of
the block, in particular break; doesn't work because it provides no
enclosing loop or switch statement.

Lawrence

[Lawrence Kirby]

On Wed, 06 Jul 2005 06:19:44 +0000, Richard Bos wrote:

CBFalconer <cb********@yahoo.com> wrote:

Mark wrote:

> then why not:
> while(EXIT_FAILURE)
> or
> while(! EXIT_SUCCESS)
> I'll tell you why not... because it's stupid! :)

A better reason is that you have absolutely no idea what those
statements will do, because you don't know the values of those
macros.

Well, half. You don't know that EXIT_SUCCESS is zero, so you don't know
that the second loop will go on indefinitely; but you do know that the
first is an unending loop, because EXIT_FAILURE cannot possibly compare
equal to 0 (since if it were, exit(EXIT_FAILURE) and exit(0) would be
identical).

There's nothing in C that prohibits this. For an example an implementation
that ignores the return value of main()/argument of exit() need make no
distinction between a success and failure value.

Lawrence

[Alan Balmer]

On 5 Jul 2005 18:56:11 -0700, "Me" <an*****************@yahoo.com>
wrote:

in some cases like dynamic memory allocation I find it convenient to
(ab-)use for() or while() like this:
/* (allocate memory) */

for(;;){ /* alternatively: while(TRUE){ */

/* (other code) */

break;
}

/* (free memory) */
The reason to do that is to remind the programmer who might not be me
not to forget things (like freeing memory) when inserting code later,
keep the order of commands (don't free too early) etc.

If I saw code like that I would wonder wtf you were smoking when you
wrote it. do { } while(0); is almost always the best way to express
creation of a new scope

I would prefer either the while(1) or for(;;) constructs simply
because the loop conditions are known without having to go find the
other end of the statement.

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

[Malcolm]

"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote

Since comp.lang.c _always_ operates in the specific context of C, there
is nothing wrong at all with for (;;).

But I don't write code primarily for a comp.lang.c audience. I can assume
that the reader knows C, but he may well be a statistician with limited
programming experience, mainly in mathematical type languages. Whe he sees a
construct like for(;;) it is very offputting.

[Christian Bau]

In article <da**********@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>,
"Malcolm" <re*******@btinternet.com> wrote:

"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote

Since comp.lang.c _always_ operates in the specific context of C, there
is nothing wrong at all with for (;;).

But I don't write code primarily for a comp.lang.c audience. I can assume
that the reader knows C, but he may well be a statistician with limited
programming experience, mainly in mathematical type languages. Whe he sees a
construct like for(;;) it is very offputting.

I will remember that the next time I write code with the intention of
having it read by a statistician. But for most people, writing C code
with the intention of having it read by C programmers is much more
common.

[Chris Croughton]

On Thu, 7 Jul 2005 22:33:16 +0000 (UTC), Malcolm
<re*******@btinternet.com> wrote:

"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote

Since comp.lang.c _always_ operates in the specific context of C, there
is nothing wrong at all with for (;;).

But I don't write code primarily for a comp.lang.c audience. I can assume
that the reader knows C, but he may well be a statistician with limited
programming experience, mainly in mathematical type languages. Whe he sees a
construct like for(;;) it is very offputting.

No more so than seeing the mathematically ridiculous statement x = x+1;
If anyone says thatthey "know C" and doesn't recognise for (;;) as being
a loop without a condition then they deserve to be fired because they
are misrepresenting themself.

(Yes, I have seen people come for interview who say that they are
"experienced C programmers" and don't recognise common idioms like that.
They don't get the job. I don't know who does employ them, possibly
Microsoft or the government...)

Chris C

[Guillaume]

Chris Croughton wrote:

No more so than seeing the mathematically ridiculous statement x = x+1;
Absolutely.
If anyone says thatthey "know C" and doesn't recognise for (;;) as being
a loop without a condition then they deserve to be fired because they
are misrepresenting themself.
Agree. Well, the guy was talking about someone that "may well be a
statistician with limited programming experience", though.
But that's not a valid point in my opinion. Would you submit a report
written in english to some person, maybe skilled in the field that's
dealt with in the report, but that doesn't understand half of the
english idioms? I wouldn't. Too many possibilities of misunderstandings.
So my take at this is: don't show C code to someone that doesn't know C.
That's useless. If you are going to work with someone that has "limited
programming experience", just give them the formulas and algorithms
written in natural/math language, not in C.
(Yes, I have seen people come for interview who say that they are
"experienced C programmers" and don't recognise common idioms like that.
They don't get the job. I don't know who does employ them, possibly
Microsoft or the government...)

Well, I have interviewed at Microsoft once (what was I thinking? ;-) ).
The technical interviews were actually pretty difficult; at least,
you had to solve some tricky stuff in like 40 minutes..., which, under
pressure, was too fast for me. I do remember one of the guys stating
something really stupid as to the C standard though...

(If I remember correctly, he was claiming that 'sizeof(char)'
may yield something else than 1 on some platforms. Seems to me
like 'sizeof(char) == 1' is in the standard, isn't it actually the
very definition of sizeof?.

My copy of the standard says:
"When applied to an operand that has type char, unsigned char, or signed
char, (or a qualified version thereof) the result is 1."

Oh well...)