while (1) vs. for ( ;; )

Richard Heathfield <in*****@invalid.invalid> writes:

Tim Rentsch said:
Do you really mean to say that _no_ loop, at any
time under any conditions, should be written with a constant
control expression? Not counting of course examples like
the microwave oven driver loop, which you explained already.

I'm saying that I wouldn't write such a loop. That isn't the same as
claiming that everybody must do likewise. :-)

Oh. Well if that's all you're trying to say then there
might not be any lack of agreement after all. :-)

Nov 15 '05 #102

"Default User" <de***********@yahoo.com> wrote in message
news:3n************@individual.net...

Charlie Gordon wrote:
"Default User" <de***********@yahoo.com> wrote in message
news:3n************@individual.net...
Charlie Gordon wrote:

> "Default User" <de***********@yahoo.com> wrote in message
> news:3n************@individual.net...

I have 24+ years in and would feel pretty damn stupid getting fired
over something like that.

What about my last proposition ?

It was pretty dumb too. If it's on the web, it's not there legally, and
me pointing it out would merely be assisting in several company
violations. I like my job. And its money.

Well, this is a case of prejudice.
You should still do the test, even just to find out if any similar document lies
out there on the net.
You can then try and determine which of your company's and the other is the
original one...
If it appears Boeing's rights have been tampered with, you can report your find
to the company lawyer and may even get rewarded for it.
If it is the other way around, your opinion about the corporation might suffer,
but there would be no reason left to keep these effective coding standards from
comp.lang.c's avid readers.

As far as your job is concerned, this is a risk-free experience.

Chqrlie.

Nov 15 '05 #103

In article <df**********@reader1.imaginet.fr>,
"Charlie Gordon" <ne**@chqrlie.org> wrote:

As far as your job is concerned, this is a risk-free experience.

There are cases where just looking around on the web can be a problem.

Nov 15 '05 #104

Baxter

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Baxter" <lb**************@baxcode.com> writes:
[...]
Why not code it like you would read it in English:

bool done = false;
while (!done) { // while not done do
...

bool mainloop = true;
while (mainloop) { // while mainloop do
...
Because clear English is not necessarily clear C.

It's not your job to write to the machine or to the compiler. Your job is
to write to the next guy (probably yourself) who will be reading the code.

You've declared "done" and "mainloop" as variables, which means their
values could change.
Yep.
With "while (1)" (or "for (;;)") I can see at a
glance that the loop is an infinite one;
Infinity is a very long time. Your program will absolutely stop before
then.
with your suggestion, I can
never be sure unless I analyze the program and verify that "done" will
always be false (and then I'll wonder why the heck you used a
variable).
You could also use a #define -- while (PROGRAM_IS_RUNNING) {

The clear meaning of "while (!done)" is that the variable "done"
represents a condition that will become true when the loop is meant to
terminate.
That program WILL terminate sometime. If nothing else, when the power
switch is flipped.

I assume that anyone reading my code either is familiar with C, or
just won't be able to understand the code.

Not a good assumption. Even you can mis-read your own code on a bad day -
you'll wonder the next day how you could have written such code.
--
---------------------------------------------------------------------
DataGet & PocketLog www.dataget.com
Data Collectors www.baxcode.com
--------------------------------------------------------------------

Nov 15 '05 #105

Baxter

"Charlie Gordon" <ne**@chqrlie.org> wrote in message
news:df**********@reader1.imaginet.fr...

"Baxter" <lb**************@baxcode.com> wrote in message
news:11*************@corp.supernews.com...

Why not code it like you would read it in English:

bool done = false;
while (!done) { // while not done do
do not paraphrase code in comments.

I don't - I was illustrating how one would read this in English.

Convey your intent in English (assuming English is your first language)

wrong assumption, but irrelevant.

Simple concepts are more effectively conveyed thru standard symbols*.
Fast english readers do not spell out words, or pronounce them in their

heads. Fast code readers do not like to have to read a lot of english, because in C punctuation conveys more meaning than words.
"Fast readers" are going to miss something - especially if it is not in the
language they think in.

while (!done) looks a lot like while(done) or while (idone)

for (;;) is blatantly unambiguous.

And it has nothing to do with the action/job you're trying to describe.
Write your code so that it describes what the program does.

Nov 15 '05 #106

Keith Thompson

"Baxter" <lb**************@baxcode.com> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Baxter" <lb**************@baxcode.com> writes:
[...]
> Why not code it like you would read it in English:
>
> bool done = false;
> while (!done) { // while not done do
> ...
>
> bool mainloop = true;
> while (mainloop) { // while mainloop do
> ...
Because clear English is not necessarily clear C.

It's not your job to write to the machine or to the compiler.

Of course it is.
Your job is to write to the next guy (probably yourself) who will be
reading the code.

That too.

If I write either "while (1)" or "for (;;)", the next guy will know
exactly what it means; if he doesn't, he's not going be able to
understand the rest of the program. Both are common C idioms.

If I write "while (mainloop)", the next guy won't know what it means
without tracking down what "mainloop" is. If he discovers that
"mainloop" is a variable (not a constant) of type bool, that happens
to be initiailized to true, and that is never changed, he's going to
do two things: change it to "while (1)" and track me down to ask what
I was thinking when I wrote the code.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Nov 15 '05 #107

websnarf

Tim Rentsch wrote:

Michael B Allen <mb*****@ioplex.com> writes:
Should there be any preference between the following logically equivalent
statements?

while (1) {

vs.

for ( ;; ) {

I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.
My experience is that there is less cognitive load if the
'while(1)' form is used. That is, when reading code, I can
read either form just fine, but something in my conscious
brain notices if the 'for(;;)' form is used, which slows
down my reading just a tiny bit. The 'while(1)' form gets
read and turned into "loop forever" without losing flow or
needing any conscious brain cycles. For these reasons --
that is, higher productivity -- I prefer the 'while(1)'
form.

I was surprised at how many people reported that a compiler
they use issues a warning for 'while(1)' and gave that as a
reason for giving preference to the 'for(;;)' form. It
seems like a choice should be made on the basis of what's a
better expression (lower defect rate, higher productivity,
better understood by the readers), not on the basis of some
errant warning message. Getting a warning on 'while(1)'
(assuming it can't be separately disabled) is a sign that
the person who wrote the warning code didn't think through
what he was doing, not that the construct is suspect. Style
choices should determine what kinds of warning messages come
out of the compiler, not the other way around.

These "defective warnings" come from *MANY* compilers and PC-LINT. I
agree with you that while(1) takes less default brainpower, but in the
end for(;;) has no more characters, so your brain will easily learn to
recognize that in its place. Like you I wish, the compiler warnings
and LINT programs went the other way, but they didn't. I don't know
why. But to really put some effort and making a fuss about this, I
need something else.

To me being able to say my code compiles "warning free" and 100% LINT
clean is extremely valuable. (It means that if anyone wants to
check/debug their modifications afterwards, they know that every
compiler/LINT warning will point to a modification they made that is
likely to be the place to look first.) This often forces me to write
my code slightly different from my default (like casting 'X' characters
to (char), since compilers will often make them ints by default.) But
its worth it. Because "automated checkers" are the cheapest set of
eyes looking over my shoulder to make sure my code is ok.

This heuristic has served me very well, regardless of what pain it
causes me. To give that up, just because while(1) is slightly better
intuitively, is just not a good trade off. Compiler warnings are
valuable to me -- my intuition being a replacement for accurate reading
of source code is not as valuable.
I myself would have no problem with people writing

FOREVER {
}

assuming a suitable '#define FOREVER <...>', _provided_ the
definition had made its way into a project-level include
file and was used and recognized by the team as a whole and
not just by some individuals. Doing that might be a way of
getting team consensus and simultaneously avoiding the whole
while/for discussion altogether.

Sure, but its a little nonstandard. The effort you put into propgating
and getting used to this, it seems to me, is not seriously different
from just standardizing on for(;;).

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Nov 15 '05 #108

websnarf

Tim Rentsch wrote:

Keith Thompson <ks***@mib.org> writes:
What debugging techniques are you referring to? Off the top of my
head, I'd say that any debugging technique that treats the two forms
significantly differently is broken, but I'm prepared to be
enlightened.

One technique I was thinking of is, eg,

#define while(e) while( LOOPTRACK() && (e) )

which is a technique I've found useful in the past in some
situations. You can do something similar with 'for()', but
it doesn't work quite as well because of the syntax of the
'for' control expressions; in particular, it's hard to put
the call to 'LOOPTRACK()' before the first iteration. This
technique can be especially important for loops of the "near
infinite" variety.

How about:

#define for(x) for(LOOPTRACK(),x,LOOPTRACK())

?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Nov 15 '05 #109

websnarf

Keith Thompson wrote:

Keith Thompson <ks***@mib.org> writes:
[...]
In another thread, I've railed against "if (0 = a)", even though it's
semantically identical to "if (a == 0)". And yes, I'm taking the
opposite side of this argument. The difference, which is largely in
my head, is that I don't find either "while (1)" or "for (;;)" to be
ugly or jarring.

Of course, I meant "if (0 == a)", not "if (0 = a)".

Gloating over the irony of that typo is left as an exercise for the
reader.

You know how on the Daily Show with Jon Stewart, he'll occasionally
show a clip of some government official that's just so funny or
outrageous in of itself that he doesn't even say anything when the
camera comes back to him? He just makes some subtle facial gestures
and the audience is doubling over in laughter? You know what I'm
talking about?

That's what this reminded me of.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Nov 15 '05 #110

Wolfgang Riedel

Tim Rentsch wrote:

"Charlie Gordon" <ne**@chqrlie.org> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
Tim Rentsch <tx*@alumnus.caltech.edu> writes:
> pete <pf*****@mindspring.com> writes:
<>snip grep -n 'while[ ]*([ ]*l[ ]*)'

to find them. (Add tabs next to the spaces inside brackets

<>snip

you didn't try said grep on any OS known to mankind, I guess.

On the other hand, this one will just do, what _I_ want:

grep -n ';;' *.c

Wolfgang

Nov 15 '05 #111

<we******@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

How about:

#define for(x) for(LOOPTRACK(),x,LOOPTRACK())

Yeh, that's an idea! let's get the worst of both worlds :

// To settle the while(1) / for(;;) debate, here is a compromise :

for (; 1 ;) { ... }

Chqrlie.

Nov 15 '05 #112

Wolfgang Riedel <wo*************@retarus.de> writes:

Tim Rentsch wrote:

"Charlie Gordon" <ne**@chqrlie.org> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
> Tim Rentsch <tx*@alumnus.caltech.edu> writes:
> > pete <pf*****@mindspring.com> writes:
>

<>snip
grep -n 'while[ ]*([ ]*l[ ]*)'

to find them. (Add tabs next to the spaces inside brackets

<>snip

you didn't try said grep on any OS known to mankind, I guess.

In fact, I did. The command in the posting was copied
directly out of the shell script file that had the command
in it.

If you read the earlier posting again, you should see that
the point of the grep is to find while's that look like
'while(1)' but actually have a lowercase L, rather than 1,
as the control expression. The grep command above will do
that.

Nov 15 '05 #113

we******@gmail.com writes:

Tim Rentsch wrote:
Keith Thompson <ks***@mib.org> writes:
What debugging techniques are you referring to? Off the top of my
head, I'd say that any debugging technique that treats the two forms
significantly differently is broken, but I'm prepared to be
enlightened.

One technique I was thinking of is, eg,

#define while(e) while( LOOPTRACK() && (e) )

which is a technique I've found useful in the past in some
situations. You can do something similar with 'for()', but
it doesn't work quite as well because of the syntax of the
'for' control expressions; in particular, it's hard to put
the call to 'LOOPTRACK()' before the first iteration. This
technique can be especially important for loops of the "near
infinite" variety.

How about:

#define for(x) for(LOOPTRACK(),x,LOOPTRACK())

?

A couple of problems:

1. Doing 'for(;;)' would then be a syntax error.

2. Usage like 'for( p=d, q=s; *q; p++, q++ )' would need to
be written with extra sets of parentheses for the first and
third expressions -- 'for( (p=d, q=s); *q; (p++, q++) )' --
so as to satisfy the preprocessor.

A similar requirement holds for while control expressions
that use the comma operator, but such cases are relatively
rare. It's fairly common to use multiple initializations
or multiple "next iteration actions" in for loops.

Nov 15 '05 #114

Default User

Charlie Gordon wrote:

"Default User" <de***********@yahoo.com> wrote in message
It was pretty dumb too. If it's on the web, it's not there legally,
and me pointing it out would merely be assisting in several company
violations. I like my job. And its money.

Well, this is a case of prejudice.

Boggle.
You should still do the test, even just to find out if any similar
document lies out there on the net.

I "should" do what I feel comfortable with, not what usenet people want
me to do.

Brian

Nov 15 '05 #115

we******@gmail.com writes:

Tim Rentsch wrote:
Michael B Allen <mb*****@ioplex.com> writes:
Should there be any preference between the following logically equivalent
statements?

while (1) {

vs.

for ( ;; ) {

I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

My experience is that there is less cognitive load if the
'while(1)' form is used. That is, when reading code, I can
read either form just fine, but something in my conscious
brain notices if the 'for(;;)' form is used, which slows
down my reading just a tiny bit. The 'while(1)' form gets
read and turned into "loop forever" without losing flow or
needing any conscious brain cycles. For these reasons --
that is, higher productivity -- I prefer the 'while(1)'
form.

I was surprised at how many people reported that a compiler
they use issues a warning for 'while(1)' and gave that as a
reason for giving preference to the 'for(;;)' form. It
seems like a choice should be made on the basis of what's a
better expression (lower defect rate, higher productivity,
better understood by the readers), not on the basis of some
errant warning message. Getting a warning on 'while(1)'
(assuming it can't be separately disabled) is a sign that
the person who wrote the warning code didn't think through
what he was doing, not that the construct is suspect. Style
choices should determine what kinds of warning messages come
out of the compiler, not the other way around.

These "defective warnings" come from *MANY* compilers and PC-LINT. I
agree with you that while(1) takes less default brainpower, but in the
end for(;;) has no more characters, so your brain will easily learn to
recognize that in its place. Like you I wish, the compiler warnings
and LINT programs went the other way, but they didn't. I don't know
why. But to really put some effort and making a fuss about this, I
need something else.

To me being able to say my code compiles "warning free" and 100% LINT
clean is extremely valuable. (It means that if anyone wants to
check/debug their modifications afterwards, they know that every
compiler/LINT warning will point to a modification they made that is
likely to be the place to look first.) This often forces me to write
my code slightly different from my default (like casting 'X' characters
to (char), since compilers will often make them ints by default.) But
its worth it. Because "automated checkers" are the cheapest set of
eyes looking over my shoulder to make sure my code is ok.

This heuristic has served me very well, regardless of what pain it
causes me. To give that up, just because while(1) is slightly better
intuitively, is just not a good trade off. Compiler warnings are
valuable to me -- my intuition being a replacement for accurate reading
of source code is not as valuable.

If you think using 'for(;;)' is a better match for you, given
the factors in your environment, by all means please use it.

On the other hand, don't assume that the factors and experience
of your environment must also apply to other people. My
experience using lint and other similar tools is different from
yours. Some warning messages seem cost-effective to enable;
others do not. The set of messages that seem cost-effective in
your environment doesn't necessarily match the sets in other
environments.

Incidentally, I didn't say "defective warnings", I said "errant
warning message". Please try to quote correctly, even in small
things.

I myself would have no problem with people writing

FOREVER {
}

assuming a suitable '#define FOREVER <...>', _provided_ the
definition had made its way into a project-level include
file and was used and recognized by the team as a whole and
not just by some individuals. Doing that might be a way of
getting team consensus and simultaneously avoiding the whole
while/for discussion altogether.

Sure, but its a little nonstandard. The effort you put into propgating
and getting used to this, it seems to me, is not seriously different
from just standardizing on for(;;).

I take it you haven't measured (even informally) the cost
of either one? And you're now asserting that the costs
are the same?

Even if the costs are the same, the benefits of using
the 'FOREVER { ... }' form may be higher. In choosing
between alternatives, it's important to look at both
costs and benefits.

Nov 15 '05 #116

"Charlie Gordon" <ne**@chqrlie.org> writes:

"Tim Rentsch" <tx*@alumnus.caltech.edu> wrote in message
news:kf*************@alumnus.caltech.edu...
"Charlie Gordon" <ne**@chqrlie.org> writes:
Assume the programmer always uses while(1) { ... }
for his endless loops. You quickly get used to interpreting
these automatically as you read them, without paying much
attention. What if there are some while(l) { ... } loops
as well. Will you always keep a sharp enough eye to catch
these correctly ?
This question has to deserve some kind of award for being a
strawman argument. If you need to find 'while(l)', it takes
only a few seconds to write a command:

grep -n 'while[ ]*([ ]*l[ ]*)'

to find them. (Add tabs next to the spaces inside brackets
if developers are prone to use tabs in the middle of lines.)

My intent was not to find such things, just to point out that there is a
possibility for misreading code and for miswriting it as well. That stupid
programmer might have meant while(l) and typed while(1) and then cannot tell the
difference because of a stupid Courier font. How will he/she find this bug ?

Oh. You know about a class of problems, but you don't want
to use the best tools to try to avoid them?

Pick a side. Either the problem is one that's important to
address, or it isn't. You can't have it both ways. If it's
important that the problem be addressed, I would expect any
competent software developer to try to find the most
cost-effective means of solving or avoiding it.

To go after poorly named variables, I would want to catch and flag all use of
variables named 'l' this way :
grep -nw l **/*.[hc]

To bad grep doesn't know how to ignore C comments and literals.

If grep doesn't solve this problem for you, it's really not
that difficult to write a specialized program that does
token search rather than string search. Assuming of course
that there isn't one already written that could be found
with a short web search.

Fixing them might take as long as two or three minutes; so
to save you the trouble, here's a command for that:

sed 's:\(while[ ]*(\)[ ]*l[ ]*):\1 l /*** L, NOT 1! ***/ ):'

Please feel free to use either or both of these aids
to help identify or correct such egregious code.

Thank you professor, you are so grand!
You will note that this sed script will break code where the while(l) appears in
/* comments */
or change code behaviour if it appears in C strings.

Yes, that's a shortcoming. Do you expect such things to
actually occur, or is this just a silly objection for the
purpose of scoring debate points?

In either case, both conditions are easily addressed.

1. In cases where 'while(l)' appears inside comments, the
new code will get an error message out of the compiler.
Use an editor and fix the problem. (Does anyone still
use comments rather than '#if 0' to comment out sections
of code?)

2. In cases where 'while(l)' appears inside strings (or
character literals), these can be found easily using
diff and grep. Use an editor and fix them.
When I wrote my earlier response, I assumed that there some
level of legitimate concern for an actual potential problem.
Now it appears that you are objecting solely for the purpose
of raising objections, and not because you have any interest
in solving a problem. If so, please do everyone a favor and
just go away.

Nov 15 '05 #117

Alan Balmer

On Wed, 31 Aug 2005 21:12:25 -0700, "Baxter"
<lb**************@baxcode.com> wrote:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Baxter" <lb**************@baxcode.com> writes:
[...]
> Why not code it like you would read it in English:
>
> bool done = false;
> while (!done) { // while not done do
> ...
>
> bool mainloop = true;
> while (mainloop) { // while mainloop do
> ...
Because clear English is not necessarily clear C.

It's not your job to write to the machine or to the compiler. Your job is
to write to the next guy (probably yourself) who will be reading the code.

Do you know any C programmer who would have difficulty reading this
code? Would you?

You've declared "done" and "mainloop" as variables, which means their
values could change.

Yep.
With "while (1)" (or "for (;;)") I can see at a
glance that the loop is an infinite one;

Infinity is a very long time. Your program will absolutely stop before
then.

You are unfamiliar with the term "infinite loop"?
with your suggestion, I can
never be sure unless I analyze the program and verify that "done" will
always be false (and then I'll wonder why the heck you used a
variable).
You could also use a #define -- while (PROGRAM_IS_RUNNING) {

Why? Since we are indeed writing a computer program, not a novel, I
still have to go find the definition of PROGRAM_IS_RUNNING.

The clear meaning of "while (!done)" is that the variable "done"
represents a condition that will become true when the loop is meant to
terminate.

That program WILL terminate sometime. If nothing else, when the power
switch is flipped.

Are you saying that the power switch will change the value of "done"?
I suspect that's implementation-dependent.

I assume that anyone reading my code either is familiar with C, or
just won't be able to understand the code.

Not a good assumption. Even you can mis-read your own code on a bad day -
you'll wonder the next day how you could have written such code.

Much more likely to happen if you obfuscate the code in the ways
you're suggesting.
--
Al Balmer
Balmer Consulting
re************************@att.net

Nov 15 '05 #118

Flash Gordon

we******@gmail.com wrote:

Tim Rentsch wrote:
Michael B Allen <mb*****@ioplex.com> writes:
Should there be any preference between the following logically equivalent
statements?

while (1) {

vs.

for ( ;; ) {

I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.
My experience is that there is less cognitive load if the
'while(1)' form is used. That is, when reading code, I can
read either form just fine, but something in my conscious
brain notices if the 'for(;;)' form is used, which slows
down my reading just a tiny bit. The 'while(1)' form gets
read and turned into "loop forever" without losing flow or
needing any conscious brain cycles. For these reasons --
that is, higher productivity -- I prefer the 'while(1)'
form.

I was surprised at how many people reported that a compiler
they use issues a warning for 'while(1)' and gave that as a
reason for giving preference to the 'for(;;)' form. It
seems like a choice should be made on the basis of what's a
better expression (lower defect rate, higher productivity,
better understood by the readers), not on the basis of some
errant warning message. Getting a warning on 'while(1)'
(assuming it can't be separately disabled) is a sign that
the person who wrote the warning code didn't think through
what he was doing, not that the construct is suspect. Style
choices should determine what kinds of warning messages come
out of the compiler, not the other way around.

These "defective warnings" come from *MANY* compilers and PC-LINT.

I don't consider the warning to be defective. You can have conditions
which always evaluate to true or false for a number of reasons:

1) It will evaluate to a different value on some other implementation
leading to different behaviour and this is correct.
Why not use #if to select the appropriate behaviour so that it is
obvious that it never changes for a given build?

2) You are doing an "infinite" loop (it might break out from the middle)
and the for (;;) idiom can be used in this instance.

3) You've made an error (maybe due to mixing signed and unsigned or
something) and the condition should *not* always evaluate to the same
value.

How many instances are there where you need a conditional with a
constant expression that can't be easily implemented using #if or for
(;;) or similar? If you can't find any, then by not having the warning
you would be throwing away the chance for the tools to inform you of
real errors.
I
agree with you that while(1) takes less default brainpower, but in the
end for(;;) has no more characters, so your brain will easily learn to
recognize that in its place.
for (;;) does not (and never has) taken *me* any more brain power, since
I see immediately that there is no termination condition so the loop is
never terminated from there. Of course, other people might find it takes
more work to read.
Like you I wish, the compiler warnings
and LINT programs went the other way, but they didn't. I don't know
why. But to really put some effort and making a fuss about this, I
need something else.
I prefer to have compilers warn about conditionals that always evaluate
to the same value.
To me being able to say my code compiles "warning free" and 100% LINT
clean is extremely valuable. (It means that if anyone wants to
check/debug their modifications afterwards, they know that every
compiler/LINT warning will point to a modification they made that is
likely to be the place to look first.) This often forces me to write
my code slightly different from my default (like casting 'X' characters
to (char), since compilers will often make them ints by default.) But
its worth it. Because "automated checkers" are the cheapest set of
eyes looking over my shoulder to make sure my code is ok.
Agreed.
This heuristic has served me very well, regardless of what pain it
causes me. To give that up, just because while(1) is slightly better
intuitively, is just not a good trade off. Compiler warnings are
valuable to me -- my intuition being a replacement for accurate reading
of source code is not as valuable.

For me while(1) is not more intuitive than for (;;). I'm not disputing
it is for you, just pointing out that for some of us there is not the
down side you have.

I myself would have no problem with people writing

FOREVER {
}

assuming a suitable '#define FOREVER <...>', _provided_ the
definition had made its way into a project-level include
file and was used and recognized by the team as a whole and
not just by some individuals. Doing that might be a way of
getting team consensus and simultaneously avoiding the whole
while/for discussion altogether.

Sure, but its a little nonstandard. The effort you put into propgating
and getting used to this, it seems to me, is not seriously different
from just standardizing on for(;;).

I definitely agree here. Both while(1) and for(;;) are perfectly clear
if you no C, and I can see no instance where you would want to change
all instances of FOREVER to something other than an infinite loop, so it
adds something non-standard to be learned (you have to learn to always
use it) with no significant benefit that I can see.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

Nov 15 '05 #119

Keith Thompson

Flash Gordon <sp**@flash-gordon.me.uk> writes:

we******@gmail.com wrote:
Tim Rentsch wrote: [...]
I was surprised at how many people reported that a compiler
they use issues a warning for 'while(1)' and gave that as a
reason for giving preference to the 'for(;;)' form. It
seems like a choice should be made on the basis of what's a
better expression (lower defect rate, higher productivity,
better understood by the readers), not on the basis of some
errant warning message. Getting a warning on 'while(1)'
(assuming it can't be separately disabled) is a sign that
the person who wrote the warning code didn't think through
what he was doing, not that the construct is suspect. Style
choices should determine what kinds of warning messages come
out of the compiler, not the other way around.

These "defective warnings" come from *MANY* compilers and PC-LINT.

I don't consider the warning to be defective. You can have conditions
which always evaluate to true or false for a number of reasons:

1) It will evaluate to a different value on some other implementation
leading to different behaviour and this is correct.
Why not use #if to select the appropriate behaviour so that it is
obvious that it never changes for a given build?

2) You are doing an "infinite" loop (it might break out from the middle)
and the for (;;) idiom can be used in this instance.

3) You've made an error (maybe due to mixing signed and unsigned or
something) and the condition should *not* always evaluate to the same
value.

Yes, a lint-like tool or a smart compiler should be able to warn about
conditions that always evaluate to true or false. But anything clever
enough to warn about constant conditions should be clever enough to
recognize the common "while (1)" idiom and shut up about it.

That doesn't, of course, mean that all such tools actually do make
this distinction, and we still have to deal with the ones that don't.
But if you're using something that warns about "while (1)" but not
about the equivalent "for (;;)", you might consider submitting a bug
report.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Nov 15 '05 #120

Baxter

"Alan Balmer" <al******@att.net> wrote in message
news:u0********************************@4ax.com...

On Wed, 31 Aug 2005 21:12:25 -0700, "Baxter"
<lb**************@baxcode.com> wrote:

With "while (1)" (or "for (;;)") I can see at a
glance that the loop is an infinite one;

Infinity is a very long time. Your program will absolutely stop before
then.

You are unfamiliar with the term "infinite loop"?

And how many infinite loops should there be in your program?

Myself, I've got over a million lines of code I've written without any need
of an infinite loop. Some of the code I've inherited has them - but in
EVERY case, they have one or more exit conditions -- and thus _are_not_
actually infinite loops.

Sounds like some here are mis-using this kind of loop.

Nov 15 '05 #121

"Tim Rentsch" <tx*@alumnus.caltech.edu> wrote in message
news:kf*************@alumnus.caltech.edu...

"Charlie Gordon" <ne**@chqrlie.org> writes: ....
Fixing them might take as long as two or three minutes; so
to save you the trouble, here's a command for that:

sed 's:\(while[ ]*(\)[ ]*l[ ]*):\1 l /*** L, NOT 1! ***/ ):'

Please feel free to use either or both of these aids
to help identify or correct such egregious code.

Thank you professor, you are so grand!
You will note that this sed script will break code where the while(l) appears in /* comments */
or change code behaviour if it appears in C strings.

Yes, that's a shortcoming. Do you expect such things to
actually occur, or is this just a silly objection for the
purpose of scoring debate points?

What do you think your attitude called for, patronizing me with scripting aids,
as if I couldn't figure how to search and replace when this was not even the
issue at all ?
In either case, both conditions are easily addressed.

1. In cases where 'while(l)' appears inside comments, the
new code will get an error message out of the compiler.
Use an editor and fix the problem. (Does anyone still
use comments rather than '#if 0' to comment out sections
of code?)
Java programmers don't have much of a choice, and they keep doing it when they
switch to C.
I hate this, but it does happen in real life, I see it every day.
Don't tell me this can be solved by preprocessing java code, that's indeed what
we do, but I cannot control the rest of the crowd.
2. In cases where 'while(l)' appears inside strings (or
character literals), these can be found easily using
diff and grep. Use an editor and fix them.
Had this been the issue, I would have easily searched and fixed them in the
general case, with a regex-file-query-replace.
Automation has its shortcomings. Honed tools are the answer.
When I wrote my earlier response, I assumed that there some
level of legitimate concern for an actual potential problem.
Now it appears that you are objecting solely for the purpose
of raising objections, and not because you have any interest
in solving a problem. If so, please do everyone a favor and
just go away.

Badly named variables are an actual problem.

This debate looked rather vain at first, but it seem to go a little bit beyond
simple style issues.
The objection I raised may seem futile to you, but it makes me want to see
neither while(1) not while(l) in any code my people will produce. This answers
the original question.

Chqrlie.

Nov 15 '05 #122

"Tim Rentsch" <tx*@alumnus.caltech.edu> wrote in message
news:kf*************@alumnus.caltech.edu...

Wolfgang Riedel <wo*************@retarus.de> writes:
Tim Rentsch wrote:

"Charlie Gordon" <ne**@chqrlie.org> writes:

> "Keith Thompson" <ks***@mib.org> wrote in message
> news:ln************@nuthaus.mib.org...
> > Tim Rentsch <tx*@alumnus.caltech.edu> writes:
> > > pete <pf*****@mindspring.com> writes:
> >

<>snip
grep -n 'while[ ]*([ ]*l[ ]*)'

to find them. (Add tabs next to the spaces inside brackets

<>snip

you didn't try said grep on any OS known to mankind, I guess.

In fact, I did. The command in the posting was copied
directly out of the shell script file that had the command
in it.

If you read the earlier posting again, you should see that
the point of the grep is to find while's that look like
'while(1)' but actually have a lowercase L, rather than 1,
as the control expression. The grep command above will do
that.

My point was not what you thought I meant:
When both while(1) and while(l) are used in a program, one can easily mistake
one for the other, if they can at all be distinguished in font used for display.
Because of this, I recomend to not use either construct. and not call variables
l.

Chqrlie.

Nov 15 '05 #123

In article <11*************@corp.supernews.com>,
"Baxter" <lb**************@baxcode.com> wrote:

"Keith Thompson" <ks***@mib.org> wrote in message

Because clear English is not necessarily clear C.

It's not your job to write to the machine or to the compiler. Your job is
to write to the next guy (probably yourself) who will be reading the code.

I expect the person who reads my C code to be able to understand C. I
don't care if she or he understands English.

Nov 15 '05 #124

In article <df**********@reader1.imaginet.fr>,
"Charlie Gordon" <ne**@chqrlie.org> wrote:

<we******@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
How about:

#define for(x) for(LOOPTRACK(),x,LOOPTRACK())

Yeh, that's an idea! let's get the worst of both worlds :

// To settle the while(1) / for(;;) debate, here is a compromise :

for (; 1 ;) { ... }

A "compromise" that combines the worst aspects of both styles...

Nov 15 '05 #125

Alan Balmer

On Thu, 1 Sep 2005 13:40:13 -0700, "Baxter"
<lb**************@baxcode.com> wrote:

"Alan Balmer" <al******@att.net> wrote in message
news:u0********************************@4ax.com.. .
On Wed, 31 Aug 2005 21:12:25 -0700, "Baxter"
<lb**************@baxcode.com> wrote:

>
>>With "while (1)" (or "for (;;)") I can see at a
>> glance that the loop is an infinite one;
>
>Infinity is a very long time. Your program will absolutely stop before
>then.

You are unfamiliar with the term "infinite loop"?

And how many infinite loops should there be in your program?

Myself, I've got over a million lines of code I've written without any need
of an infinite loop. Some of the code I've inherited has them - but in
EVERY case, they have one or more exit conditions -- and thus _are_not_
actually infinite loops.

Sounds like some here are mis-using this kind of loop.

It's a language problem. You confuse English with programming
languages and programmers' jargon :-)
--
Al Balmer
Balmer Consulting
re************************@att.net

Nov 15 '05 #126

"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote in message
news:ch*********************************@slb-newsm1.svr.pol.co.uk...

In article <df**********@reader1.imaginet.fr>,
"Charlie Gordon" <ne**@chqrlie.org> wrote:
<we******@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
How about:

#define for(x) for(LOOPTRACK(),x,LOOPTRACK())

Yeh, that's an idea! let's get the worst of both worlds :

// To settle the while(1) / for(;;) debate, here is a compromise :

for (; 1 ;) { ... }

A "compromise" that combines the worst aspects of both styles...

We can make these "infinite" loops "evil" too :

for (6;6;6) { ... }

--
Chqrlie

Nov 15 '05 #127

Richard Heathfield

Default User said:

Charlie Gordon wrote:
"Default User" <de***********@yahoo.com> wrote in message

> It was pretty dumb too. If it's on the web, it's not there legally,
> and me pointing it out would merely be assisting in several company
> violations. I like my job. And its money.

Well, this is a case of prejudice.

Boggle.
You should still do the test, even just to find out if any similar
document lies out there on the net.

I "should" do what I feel comfortable with, not what usenet people want
me to do.

Brian, I think you forgot to read the small print. Check page 137829, para
19031.9.177.12.753(j), subsection 3 of your Usenet agreement.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29 July 1999
http://www.cpax.org.uk
Email rjh at the above domain

Nov 15 '05 #128

Default User

Richard Heathfield wrote:

Default User said:

I "should" do what I feel comfortable with, not what usenet people
want me to do.

Brian, I think you forgot to read the small print. Check page 137829,
para 19031.9.177.12.753(j), subsection 3 of your Usenet agreement.

Ah yes, the "High-Handed Law". I forgot about that.

Brian

Nov 15 '05 #129

Flash Gordon <sp**@flash-gordon.me.uk> writes:

we******@gmail.com wrote:
Tim Rentsch wrote:
Michael B Allen <mb*****@ioplex.com> writes:

Should there be any preference between the following logically equivalent
statements?

while (1) {

vs.

for ( ;; ) {

I suspect the answer is "no" but I'd like to know what the consensus is
so that it doesn't blink through my mind anymore when I type it.

My experience is that there is less cognitive load if the
'while(1)' form is used. That is, when reading code, I can
read either form just fine, but something in my conscious
brain notices if the 'for(;;)' form is used, which slows
down my reading just a tiny bit. The 'while(1)' form gets
read and turned into "loop forever" without losing flow or
needing any conscious brain cycles. For these reasons --
that is, higher productivity -- I prefer the 'while(1)'
form.

I was surprised at how many people reported that a compiler
they use issues a warning for 'while(1)' and gave that as a
reason for giving preference to the 'for(;;)' form. It
seems like a choice should be made on the basis of what's a
better expression (lower defect rate, higher productivity,
better understood by the readers), not on the basis of some
errant warning message. Getting a warning on 'while(1)'
(assuming it can't be separately disabled) is a sign that
the person who wrote the warning code didn't think through
what he was doing, not that the construct is suspect. Style
choices should determine what kinds of warning messages come
out of the compiler, not the other way around.
These "defective warnings" come from *MANY* compilers and PC-LINT.

I don't consider the warning to be defective.

Note that "defective warnings" was intended by websnarf as
ironic. The original phrase was "errant warning message".
Being able to get a warning for loop control expressions
that are constant is perfectly ok; it is the message for
the particular case of 'while(1)' that is errant. The
followup by Keith Thompson articulates this nicely.

You can have conditions
which always evaluate to true or false for a number of reasons:

1) It will evaluate to a different value on some other implementation
leading to different behaviour and this is correct.
Why not use #if to select the appropriate behaviour so that it is
obvious that it never changes for a given build?
First, this approach applies to if's rather than while/for,
so it's not really germane to the topic under discussion,
which is warnings for 'while' control expressions that
are constant.

Second, using '#if' when 'if' can be used instead seems like
a step backwards. One nice thing about writing code with
'if' rather than '#if' is that the code in the conditional
always gets compiled (and so must compile correctly). Also,
consider something like:

if( DEFINED_1_OR_0 ) ...
else if( x > y ) ...
else ...

This code fragment can be rewritten using #if, but the form
of the result suffers.

As a development practice I always recommend using #if only
for sections of code that simply won't compile on other
platforms. There are of course some cases where it's better
to make an exception, but by and large code that uses 'if'
rather than '#if' tends to be more reliable and easier to
work on.

2) You are doing an "infinite" loop (it might break out from the middle)
and the for (;;) idiom can be used in this instance.
This statement presumes that there is never any reason to
prefer 'while(1)' to 'for(;;)', so the reasoning here is
rather circular. Contrary to the presumption, several
different reasons have been given for preferring the
'while(1)' form.

3) You've made an error (maybe due to mixing signed and unsigned or
something) and the condition should *not* always evaluate to the same
value.
Sure, but that doesn't have to do with looping necessarily.
The -W flag in gcc will generate warnings for expressions
like 'x >= 0' if x is unsigned. The concern is that the
expression is unexpectedly constant. The '1' in 'while(1)'
is constant, but it is not *unexpectely* constant.

[various comments that Flash prefers using 'for'
for infinite looping, and getting warnings for
any constant "conditional expression"]

For me while(1) is not more intuitive than for (;;). I'm not disputing
it is for you, just pointing out that for some of us there is not the
down side you have.

Yes, I understood that. I'm not advocating that anyone stop
using 'for(;;)'. However, I think it's a mistake to make a
choice of this kind just because there's some warning
message that flags one form or the other. You wouldn't stop
using 'for(;;)' just because some compiler decided to issue
a warning message for it, would you? Yet from my point of
view such a warning message has a (small) positive value (as
long as it can be turned off).

I myself would have no problem with people writing

FOREVER {
}

assuming a suitable '#define FOREVER <...>', _provided_ the
definition had made its way into a project-level include
file and was used and recognized by the team as a whole and
not just by some individuals. Doing that might be a way of
getting team consensus and simultaneously avoiding the whole
while/for discussion altogether.

Sure, but its a little nonstandard. The effort you put into propgating
and getting used to this, it seems to me, is not seriously different
from just standardizing on for(;;).

I definitely agree here. Both while(1) and for(;;) are perfectly clear
if you no C, and I can see no instance where you would want to change
all instances of FOREVER to something other than an infinite loop, so it
adds something non-standard to be learned (you have to learn to always
use it) with no significant benefit that I can see.

Note that I wasn't advocating that 'FOREVER' be used; only
that I wouldn't have a problem with it if the team decided
that it should be used.

As for benefits, there are at least three potential benefits:

1. It stands out. It's nice to be able to pick out easily
the places infinite loops appear, especially if you
believe that infinite loops usually should be recast
so that they are not infinite. (The "infinite" here
really means "apparently infinite"; most "infinite"
loops have break's or return's that stop them from
being actual infinite loops.)

2. There can be benefit to being able to change what
happens during infinite looping, as noted in other
messages in this tree. You should be able to find
these if you use google groups and search for
'LOOPTRACK'.

3. If there is team consensus that 'FOREVER' should be
used, that itself is a benefit; having a team be
more unified provides positive value.

Whether these benefits are worth the costs naturally
depends on what the costs are judged to be.

Nov 15 '05 #130

Thad Smith

Kevin Handy wrote:

Chris McDonald wrote:

Preference? Why not move on to something whose intention is clear:

while(true) {

Why not use

while(is_the_pope_catholic) {

Challenge your reader:
while (2+2 == 4) or
while (1+1+1 == 6/2) or
while (24+7 == 24|7) or
???

They should evaluate to a suitable constant.

Is the following always portable?

#include <stdio.h>
int main(void) {
int a;
if (a | !a) printf ("Always\n");
return 0;
}
Thad

Nov 15 '05 #131

Richard Heathfield

Thad Smith said:

Kevin Handy wrote:
Is the following always portable?

#include <stdio.h>
int main(void) {
int a;
if (a | !a) printf ("Always\n");
return 0;
}

In a curious way, it is! There is at least one guarantee that we have about
this program's behaviour under any conforming implementation. Kudos to
non-regulars who spot which guarantee I'm talking about.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/2005
http://www.cpax.org.uk
email: rjh at above domain

Nov 15 '05 #132

Thad Smith

Flash Gordon wrote:

I don't consider the warning to be defective. You can have conditions
which always evaluate to true or false for a number of reasons:

1) It will evaluate to a different value on some other implementation
leading to different behaviour and this is correct.
Why not use #if to select the appropriate behaviour so that it is
obvious that it never changes for a given build?

The expression is less messy without the separate #if / #endif lines.

I encountered a situation today with (the equivalent of)

sysparams.h
#define MIN_AREA_ADDR 0x00 /* minimum allowed EE write address */
#define MAX_AREA_ADDR 0x3f /* maximum allowed EE write address */

code.c:
#include "sysparams.h>
unsigned char addr;
...
addr = get_addr();
if (addr >= MIN_AREA_ADDR && addr <= MAX_AREA_ADDR) {
write_eeprom (addr, data);
}

The compiler issued a warning that addr >= MIN_AREA_ADDR was always
true. With this particular value, it was, but I would rather not get
the warning. I could do something like

if (
#if MIN_AREA_ADDR > 0
addr >= MIN_AREA_ADDR &&
#endif
addr <= MAX_AREA_ADDR) {

but that seems messy.

The ideal situation, for me, would be something like

#define NOWARN(x) _Pragma("-warning") x _Pragma(".warning")
...
if (NOWARN(addr >= MIN_AREA_ADDR) && addr <= MAX_AREA_ADDR) {

That's still messy, but I would rather add a little mess to suppress the
expected warning in known locations, but still look for the error in
unexpected places.

Thad

Nov 15 '05 #133

Barry Schwarz

On Sat, 03 Sep 2005 01:18:58 -0600, Thad Smith <Th*******@acm.org>
wrote:

snip

Is the following always portable?

#include <stdio.h>
int main(void) {
int a;
if (a | !a) printf ("Always\n");
return 0;
}

Precisely the opposite.
<<Remove the del for email>>

Nov 15 '05 #134

Dave Thompson

On 30 Aug 2005 18:33:38 GMT, mw*****@newsguy.com (Michael Wojcik)
wrote:

In article <43***************@retarus.de>, Wolfgang Riedel <wo*************@retarus.de> writes:
Richard Heathfield wrote:
In the cases where you are sure the parameters are okay, you can call the
function directly, avoiding the overhead of the parameter check. (You could
reasonably add assertion checks here, since they cannot possibly fire if
your program is correct.)

When you're not sure, you call the validation function - which either calls
the "do it" function directly or, perhaps slightly more cleanly, returns an
"everything's fine" value, after which you can proceed to call the "do it"
function yourself.
IIRC that's one reason, why COBOL has multiple entry points into functions.

<OT>
COBOL doesn't have multiple entry points into functions. Functions
in COBOL are a fairly restrictive language feature. I suspect you're
thinking of "programs", which is what COBOL calls the things that are
closest to what C calls "functions", or what are sometimes called
"subroutines".

Actually it calls them 'program-units'. I don't believe 'program' is
officially defined but is generally taken to be a collection, usually
link-edited, of progam-units, which officially is a 'run-unit'.
Fortran and Ada similarly have 'subprogram's linked into a program.
Standard COBOL does not permit multiple entry points in programs, but
it's an extension in several popular implementations.
</OT>
FWIW, (standard) Fortran does. And (no surprise) PL/I. But IIRC PL/I
does not allow the parameter/formal list to vary, as Fortran does,
which (latter) provides great opportunity for error both in
implementation and in usage.
Multiple entry points would certainly be *a* way of implementing the
design Richard describes, but I don't see much justification for
using them that way. Just using two functions would be clearer and
less error-prone, I suspect. And it strikes me as unlikely that,
conversely, this design would be used to argue for allowing multiple
entry points in a language.
Agree there.
I must admit, though, that I'm not fond of Richard's scheme in most
cases; unless a function is time-critical or the checks are very
expensive I don't see the advantage to skipping the checks. That
shifts the burden of validation from the program to the programmer.

AIUI Eiffel requires (well, strongly encourages) you to designate
preconditions for routines (OOishly called 'features') which it
promotes to callers, and may then be able to optimize away.

- David.Thompson1 at worldnet.att.net

Nov 15 '05 #135

In article <43***********************@auth.newsreader.octanew s.com>,
Thad Smith <Th*******@acm.org> wrote:

Flash Gordon wrote:
I don't consider the warning to be defective. You can have conditions
which always evaluate to true or false for a number of reasons:

1) It will evaluate to a different value on some other implementation
leading to different behaviour and this is correct.
Why not use #if to select the appropriate behaviour so that it is
obvious that it never changes for a given build?

The expression is less messy without the separate #if / #endif lines.

I encountered a situation today with (the equivalent of)

sysparams.h
#define MIN_AREA_ADDR 0x00 /* minimum allowed EE write address */
#define MAX_AREA_ADDR 0x3f /* maximum allowed EE write address */

code.c:
#include "sysparams.h>
unsigned char addr;
...
addr = get_addr();
if (addr >= MIN_AREA_ADDR && addr <= MAX_AREA_ADDR) {
write_eeprom (addr, data);
}

The compiler issued a warning that addr >= MIN_AREA_ADDR was always
true. With this particular value, it was, but I would rather not get
the warning. I could do something like

if (
#if MIN_AREA_ADDR > 0
addr >= MIN_AREA_ADDR &&
#endif
addr <= MAX_AREA_ADDR) {

but that seems messy.

In similar situations, I have written

if ((unsigned int) (addr - MIN_AREA_ADDR) <=
(unsigned int) (MAX_AREA_ADDR - MIN_AREA_ADDR))

with a suitable comment why such stupid code would be required. I can
feel your pain.

A heuristics to be used in a good compiler that picks this case and
avoids the warning is not too difficult: The warning is there because
with a value of addr == MIN_AREA_ADDR - 1 the test "addr >=
MIN_AREA_ADDR" would be unexpectedly true instead of false (potential
bug). However, the complete test "addr >= MIN_AREA_ADDR && addr <=
MAX_AREA_ADDR" would still give the expected result!

Nov 15 '05 #136

Baxter

"Alan Balmer" <al******@att.net> wrote in message
news:qu********************************@4ax.com...

On Thu, 1 Sep 2005 13:40:13 -0700, "Baxter"
<lb**************@baxcode.com> wrote:

"Alan Balmer" <al******@att.net> wrote in message
news:u0********************************@4ax.com.. .
On Wed, 31 Aug 2005 21:12:25 -0700, "Baxter"
<lb**************@baxcode.com> wrote:

>
>>With "while (1)" (or "for (;;)") I can see at a
>> glance that the loop is an infinite one;
>
>Infinity is a very long time. Your program will absolutely stop before >then.

You are unfamiliar with the term "infinite loop"?

And how many infinite loops should there be in your program?

Myself, I've got over a million lines of code I've written without any needof an infinite loop. Some of the code I've inherited has them - but in
EVERY case, they have one or more exit conditions -- and thus _are_not_
actually infinite loops.

Sounds like some here are mis-using this kind of loop.

It's a language problem. You confuse English with programming
languages and programmers' jargon :-)

I don't confuse anything - because I write in English and not in
computerese.
--
---------------------------------------------------------------------
DataGet & PocketLog www.dataget.com
Data Collectors www.baxcode.com
--------------------------------------------------------------------

Nov 15 '05 #137

Steven Kobes

Quoting Thad Smith:

Is the following always portable?

#include <stdio.h>
int main(void) {
int a;
if (a | !a) printf ("Always\n");
return 0;
}
Quoting Richard Heathfield: In a curious way, it is! There is at least one guarantee that we
have about this program's behaviour under any conforming
implementation. Kudos to non-regulars who spot which guarantee I'm
talking about.

I give up... what guarantee are you talking about?

Nov 15 '05 #138

Barry Schwarz

On Sun, 04 Sep 2005 10:47:20 -0700, Steven Kobes
<st*********@hotmail.com> wrote:

Quoting Thad Smith:
Is the following always portable?

#include <stdio.h>
int main(void) {
int a;
if (a | !a) printf ("Always\n");
return 0;
}

Quoting Richard Heathfield:
In a curious way, it is! There is at least one guarantee that we
have about this program's behaviour under any conforming
implementation. Kudos to non-regulars who spot which guarantee I'm
talking about.

I give up... what guarantee are you talking about?

It's been a couple of days so here is a hint. Think of the most
common types of undefined behavior. I think this is in the top five,
probably #1 or #2. Some compilers even generate a diagnostic for
this.
<<Remove the del for email>>

Nov 15 '05 #139

Alexei A. Frounze

"Barry Schwarz" <sc******@deloz.net> wrote in message
news:q3********************************@4ax.com...

On Sun, 04 Sep 2005 10:47:20 -0700, Steven Kobes
<st*********@hotmail.com> wrote:
Quoting Thad Smith:
Is the following always portable?

#include <stdio.h>
int main(void) {
int a;
if (a | !a) printf ("Always\n");
return 0;
}

Quoting Richard Heathfield:
In a curious way, it is! There is at least one guarantee that we
have about this program's behaviour under any conforming
implementation. Kudos to non-regulars who spot which guarantee I'm
talking about.

I give up... what guarantee are you talking about?

It's been a couple of days so here is a hint. Think of the most
common types of undefined behavior. I think this is in the top five,
probably #1 or #2. Some compilers even generate a diagnostic for
this.

IMO, the above may be warned as use of uninitialized variable.
And the actual problem maybe the mighty trap taking on trap representation
of uninitialized int.
If it wasn't for the last one, there would be no reason to warn at all on
either (a | !a) or (a & !a), because both would always evaluate to constant,
no matter what the (valid) values of a are...

Alex

Nov 15 '05 #140

Richard Heathfield

Steven Kobes said:

Quoting Thad Smith:
Is the following always portable?

#include <stdio.h>
int main(void) {
int a;
if (a | !a) printf ("Always\n");
return 0;
}

Quoting Richard Heathfield:
In a curious way, it is! There is at least one guarantee that we
have about this program's behaviour under any conforming
implementation. Kudos to non-regulars who spot which guarantee I'm
talking about.

I give up... what guarantee are you talking about?

Sorry for the late reply - I've been busy.

And another sorry, for of course it was a trick question. The guarantee we
have about the behaviour of this program, under any conforming
implementation, is that it (the program's behaviour) is undefined.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/2005
http://www.cpax.org.uk
email: rjh at above domain

Nov 15 '05 #141

"Alexei A. Frounze" <al*****@chat.ru> writes:

"Barry Schwarz" <sc******@deloz.net> wrote in message
news:q3********************************@4ax.com...
On Sun, 04 Sep 2005 10:47:20 -0700, Steven Kobes
<st*********@hotmail.com> wrote:
Quoting Thad Smith:
> Is the following always portable?
>
> #include <stdio.h>
> int main(void) {
> int a;
> if (a | !a) printf ("Always\n");
> return 0;
> }

[snip]

IMO, the above may be warned as use of uninitialized variable.
And the actual problem maybe the mighty trap taking on trap representation
of uninitialized int.
If it wasn't for the last one, there would be no reason to warn at all on
either (a | !a) or (a & !a), because both would always evaluate to constant,
no matter what the (valid) values of a are...

If 'a' is of type 'int', the expression 'a | !a' can produce undefined
behavior even when it's guaranteed that 'a' has a valid value.

Nov 15 '05 #142

Tim Rentsch <tx*@alumnus.caltech.edu> writes:

[snip]

If 'a' is of type 'int', the expression 'a | !a' can produce undefined
behavior even when it's guaranteed that 'a' has a valid value.

Sorry, I misspoke.

Nov 15 '05 #143

Giorgos Keramidas

Chris McDonald <ch***@csse.uwa.edu.au> writes:

I would suggest that both while(1) and for(;;) are potentially unclear
to a person (undergrad. student) seeing C for the first time
(while assuming they haven't seen Java or C++, either).

OK, I suggest that while(true) is *clearer*.

Maybe. Depending on what `true' is defined to be, though, it may be
less clear and/or buggy :-)

Nov 15 '05 #144

Alexei A. Frounze

"Tim Rentsch" <tx*@alumnus.caltech.edu> wrote in message
news:kf*************@alumnus.caltech.edu...

Tim Rentsch <tx*@alumnus.caltech.edu> writes:
[snip]

If 'a' is of type 'int', the expression 'a | !a' can produce undefined
behavior even when it's guaranteed that 'a' has a valid value.

Sorry, I misspoke.

Do you mean by the above that I was right?
Or do you want to say it must have been || instead of |? But then again,
shouldn't !a be an int or should it be some special ("logical") kind of int?

Alex

Nov 15 '05 #145