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.

-- 
Scott
Validated Software
Lafayette, CO




__________ Information from ESET NOD32 Antivirus, version of virus signature database 4661 (20091204) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

"Not Really Me" <scott@validatedQWERTYsoftware.XYZZY.com> wrote in message 
news:
>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.
>
for(;;) is meaningless to anyone who doesn't know C, or even to someone with 
a reasonable but not extensive knowledge of the language.
while(1) or while(true) is used by several programming lanauges to indicate 
infinite loops.
Generally it's a bad idea to try to shut up lint. However compiler warnings 
are a bit different. A decent compiler will recognise while(1) as a special 
case, but there are lots of non-decent ones out there.

"Not Really Me" <scott@validatedQWERTYsoftware.XYZZY.com> writes:
> 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.

No.  Both forms are common C idioms; use whichever is more convenient.
("while(1)" might be clearer than "for(;;)" to someone who doesn't
know C very well, but I wouldn't worry about that.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On  4 Dec 2009 at 18:11, Malcolm McLean wrote:
> for(;;) is meaningless to anyone who doesn't know C, or even to
> someone with a reasonable but not extensive knowledge of the language.
> while(1) or while(true) is used by several programming lanauges to
> indicate infinite loops.

This sounds pretty bogus to me, Malcolm.

Plenty of C-like languages (C++ and Java certainly, probably C# too)
will accept for(;;) as an infinite loop.

And it's such a common idiom in C, that if someone reading C code
doesn't understand it and doesn't have the gumption to look up what it
means, then they're not very likely to get much out of the rest of the
code.

for(;;) is also much more elegant and compact than while(1), avoiding as
it does that ugly pseudo-boolean constant.

Not Really Me wrote:
> 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 suppose a really poor implementation could "evaluate" the "1" every time 
through the loop, comparing it to non-zero.

Aside from that, it's personal preference.

My preference is "for(;;)" since it naturally (to me, anyway) reads "forever".

-- 
Kenneth Brody

"Antoninus Twink" <nospam@nospam.invalid> wrote in message 
news:slrnhhilgi.chv.nospam@nospam.invalid...
> On  4 Dec 2009 at 18:11, Malcolm McLean wrote:
>> for(;;) is meaningless to anyone who doesn't know C, or even to
>> someone with a reasonable but not extensive knowledge of the language.
>> while(1) or while(true) is used by several programming lanauges to
>> indicate infinite loops.

> for(;;) is also much more elegant and compact than while(1), avoiding as
> it does that ugly pseudo-boolean constant.

While we're talking about aesthetics, then both for() and while() are 
cleaner.

There's a condition missing from the while statement, but then there's also 
one missing from the for(;;).

-- 
Bartc

"bartc" <bartc@freeuk.com> writes:
[...]
> While we're talking about aesthetics, then both for() and while() are
> cleaner.
>
> There's a condition missing from the while statement, but then there's
> also one missing from the for(;;).

If you mean literally "for()" and "while()", I hardly think that the
aesthetics of code that won't compile is relevant.  I personally like

    loop
        ...
    end loop;

but that's not C either.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnaaxyxzzq.fsf@nuthaus.mib.org...
> "bartc" <bartc@freeuk.com> writes:
> [...]
>> While we're talking about aesthetics, then both for() and while() are
>> cleaner.
>>
>> There's a condition missing from the while statement, but then there's
>> also one missing from the for(;;).
>
> If you mean literally "for()" and "while()", I hardly think that the
> aesthetics of code that won't compile is relevant.

That's a minor detail. I don't think allowing an empty condition on while(), 
to match the empty one in for(;;), or taking those two semicolons as read 
(since they are not separating or terminating anything), is too taxing for 
compiler maintainers.

(And for all I know, extensions might already exist for those.)

>  I personally like
>
>    loop
>        ...
>    end loop;
>
> but that's not C either.

No, that's a completely different syntax style and certainly not C. I'm 
talking about being allowed to leave out one or two characters which don't 
contribute anything.

-- 
Bartc 

"bartc" <bartc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnaaxyxzzq.fsf@nuthaus.mib.org...
>> "bartc" <bartc@freeuk.com> writes:
>> [...]
>>> While we're talking about aesthetics, then both for() and while() are
>>> cleaner.
>>>
>>> There's a condition missing from the while statement, but then there's
>>> also one missing from the for(;;).
>>
>> If you mean literally "for()" and "while()", I hardly think that the
>> aesthetics of code that won't compile is relevant.
>
> That's a minor detail. I don't think allowing an empty condition on
> while(), to match the empty one in for(;;), or taking those two
> semicolons as read (since they are not separating or terminating
> anything), is too taxing for compiler maintainers.

Typing 1 or ;; is even less taxing.

> (And for all I know, extensions might already exist for those.)

Not that I've ever seen.

If you're suggesting a change to the language (it wasn't immediately
clear to me that that was what what you meant), I don't think
this one carries its weight.  It would be easy enough for compiler
writers to implement, but the benefit would be minimal -- and any
code that used the new forms wouldn't compile with compilers that
don't yet implement them.

C already has two idiomatic ways to express an infinite loop.
I see no advantage in adding a third and a fourth.

>>  I personally like
>>
>>    loop
>>        ...
>>    end loop;
>>
>> but that's not C either.
>
> No, that's a completely different syntax style and certainly not
> C. I'm talking about being allowed to leave out one or two characters
> which don't contribute anything.

They contribute correctness.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson wrote:
> "bartc" <bartc@freeuk.com> writes:
> [...]
>> While we're talking about aesthetics, then both for() and while() are
>> cleaner.
>>
>> There's a condition missing from the while statement, but then there's
>> also one missing from the for(;;).
> 
> If you mean literally "for()" and "while()", I hardly think that the
> aesthetics of code that won't compile is relevant.  I personally like
> 
>     loop
>         ...
>     end loop;
> 
> but that's not C either.
> 
Certainly not C. It is xBASE (dBASE, FoxBASE, FoxPro, Clipper, et. al.) and 
is used in FOR/NEXT and DO WHILE/ENDDO constructs. LOOP is equivalent to 
continue; and EXIT equivalent to break;.

I prefer C but am paid to do xBASE.

-- 
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."

bartc <bartc@freeuk.com> wrote:
>While we're talking about aesthetics, then both for() and while() are 
>cleaner.

Sorry for the digression, but:

Using Pascal in college, my friend liked to use the significantly
less-clean:

    repeat
        ... 
    until false;

which always made me giggle.

-Beej

bartc wrote:
) "Antoninus Twink" <nospam@nospam.invalid> wrote in message 
) news:slrnhhilgi.chv.nospam@nospam.invalid...
)> for(;;) is also much more elegant and compact than while(1), avoiding as
)> it does that ugly pseudo-boolean constant.
)
) While we're talking about aesthetics, then both for() and while() are 
) cleaner.
)
) There's a condition missing from the while statement, but then there's also 
) one missing from the for(;;).

I think, if you're going to extend the language, that:

  do { ... }

without the while(...), would be the most intuitive infinite loop.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

bartc wrote:
> 
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnaaxyxzzq.fsf@nuthaus.mib.org...
>> "bartc" <bartc@freeuk.com> writes:
>> [...]
>>> While we're talking about aesthetics, then both for() and while() are
>>> cleaner.
>>>
>>> There's a condition missing from the while statement, but then there's
>>> also one missing from the for(;;).
>>
>> If you mean literally "for()" and "while()", I hardly think that the
>> aesthetics of code that won't compile is relevant.
> 
> That's a minor detail. I don't think allowing an empty condition on 
> while(), to match the empty one in for(;;), or taking those two 
> semicolons as read (since they are not separating or terminating 
> anything), is too taxing for compiler maintainers.
> 
> (And for all I know, extensions might already exist for those.)
> 
>>  I personally like
>>
>>    loop
>>        ...
>>    end loop;
>>
>> but that's not C either.
> 
> No, that's a completely different syntax style and certainly not C. I'm 
> talking about being allowed to leave out one or two characters which 
> don't contribute anything.

     You'll achieve *far* greater brevity by jettisoning all
that silly white space (comments are white space, too).  Try
that first, then come back if you feel a need for even more
compression.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Joe Wright <joewwright@comcast.net> writes:
> Keith Thompson wrote:
>> "bartc" <bartc@freeuk.com> writes:
>> [...]
>>> While we're talking about aesthetics, then both for() and while() are
>>> cleaner.
>>>
>>> There's a condition missing from the while statement, but then there's
>>> also one missing from the for(;;).
>>
>> If you mean literally "for()" and "while()", I hardly think that the
>> aesthetics of code that won't compile is relevant.  I personally like
>>
>>     loop
>>         ...
>>     end loop;
>>
>> but that's not C either.
>>
> Certainly not C. It is xBASE (dBASE, FoxBASE, FoxPro, Clipper,
> et. al.) and is used in FOR/NEXT and DO WHILE/ENDDO constructs. LOOP
> is equivalent to continue; and EXIT equivalent to break;.
>
> I prefer C but am paid to do xBASE.

<OT>
Actually, it's Ada.  In this context, "loop" is like C's "while (1) {",
and "end loop;" is like C's "}".  I'm not familiar with xBASE, but
from the snippets I just Googled it doesn't like it uses the same
syntax; I'm seeing see end-of-loop markers like "ENDDO" and "ENDFOR",
not "end loop".
</OT>

All of which is, of course, beside the point.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On 2009-12-04, Not Really Me <scott@validatedQWERTYsoftware.XYZZY.com> wrote:
> 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?

Even MIPS assembly language disguises the fact that in the instruction
set, an unconditional branch is actually represented like this:

  BEQ zero, zero, target   ;; zero denotes the always-zero R0 pseudo-register

in MIPS assembly language (and dis-assembly, e.g. by GNU binutils objdump),
it's usually written like this, which generates the same instruction:

  B target

Thus, while (1) is less abstract than the unconditional branch in MIPS
assembly.

On December 4, 2009 16:41, in comp.lang.c, Beej Jorgensen (beej@beej.us)
wrote:

> bartc <bartc@freeuk.com> wrote:
>>While we're talking about aesthetics, then both for() and while() are
>>cleaner.
> 
> Sorry for the digression, but:
> 
> Using Pascal in college, my friend liked to use the significantly
> less-clean:
> 
>     repeat
>         ...
>     until false;
> 
> which always made me giggle.

In C, however, we have

  do
    ...
  while(1);

which amounts to the same thing, doesn't it?

<grin>
-- 
Lew Pitcher
Master Codewright & JOAT-in-training   | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
----------      Slackware - Because I know what I'm doing.         ------

"Willem" <willem@stack.nl> wrote in message 
news:slrnhhj0pn.kge.willem@turtle.stack.nl...
> bartc wrote:
> ) "Antoninus Twink" <nospam@nospam.invalid> wrote in message
> ) news:slrnhhilgi.chv.nospam@nospam.invalid...
> )> for(;;) is also much more elegant and compact than while(1), avoiding 
> as
> )> it does that ugly pseudo-boolean constant.
> )
> ) While we're talking about aesthetics, then both for() and while() are
> ) cleaner.
> )
> ) There's a condition missing from the while statement, but then there's 
> also
> ) one missing from the for(;;).
>
> I think, if you're going to extend the language, that:
>
>  do { ... }
>
> without the while(...), would be the most intuitive infinite loop.

Yes. But that's a more substantial syntax change.

And anyway someone will be along in a minute with some tacky macros to 
emulate any loop construct you can think of, so the chances of even my 
trivial suggestion making it into the language proper are minimal.

-- 
Bartc 

On 04 Dec 2009, "Malcolm McLean" <regniztar@btinternet.com> wrote:

> "Not Really Me" <scott@validatedQWERTYsoftware.XYZZY.com> wrote
> in message news:
>>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. 
>>
> for(;;) is meaningless to anyone who doesn't know C,

Why do you say that?  This construct works in PHP, Perl, ECMAScript, 
and probably other languages that have C-like for loops.

> or even to
> someone with a reasonable but not extensive knowledge of the
> language.

Is it really that esoteric?  Personally, it never seemed that way to 
me.

<snip>

-- 
"Don't worry about efficiency until you've attained correctness."
  ~ Eric Sosman, comp.lang.c

On 2009-12-04, Willem <willem@stack.nl> wrote:
> bartc wrote:
> ) "Antoninus Twink" <nospam@nospam.invalid> wrote in message 
> ) news:slrnhhilgi.chv.nospam@nospam.invalid...
> )> for(;;) is also much more elegant and compact than while(1), avoiding as
> )> it does that ugly pseudo-boolean constant.
> )
> ) While we're talking about aesthetics, then both for() and while() are 
> ) cleaner.
> )
> ) There's a condition missing from the while statement, but then there's also 
> ) one missing from the for(;;).
>
> I think, if you're going to extend the language, that:
>
>   do { ... }
>
> without the while(...), would be the most intuitive infinite loop.

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

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

:)

"bartc" <bartc@freeuk.com> wrote in message 
news:aqgSm.11900$Ym4.10310@text.news.virginmedia.com...
>
> "Willem" <willem@stack.nl> wrote in message 
> news:slrnhhj0pn.kge.willem@turtle.stack.nl...
>> bartc wrote:
>> ) "Antoninus Twink" <nospam@nospam.invalid> wrote in message
>> ) news:slrnhhilgi.chv.nospam@nospam.invalid...
>> )> for(;;) is also much more elegant and compact than while(1), avoiding 
>> as
>> )> it does that ugly pseudo-boolean constant.
>> )
>> ) While we're talking about aesthetics, then both for() and while() are
>> ) cleaner.
>> )
>> ) There's a condition missing from the while statement, but then there's 
>> also
>> ) one missing from the for(;;).
>>
>> I think, if you're going to extend the language, that:
>>
>>  do { ... }
>>
>> without the while(...), would be the most intuitive infinite loop.
>
> Yes. But that's a more substantial syntax change.
>
> And anyway someone will be along in a minute with some tacky macros to 
> emulate any loop construct you can think of, so the chances of even my 
> trivial suggestion making it into the language proper are minimal.


#define FOREVER for (;;)


void foo()
{
    FOREVER
    {
        /* [...] */
    }
}


lol! I could not resist. 

In <pN6dna0jZtpNzYTWnZ2dnUVZ8jWdnZ2d@bt.com>, Malcolm McLean wrote:

> "Not Really Me" <scott@validatedQWERTYsoftware.XYZZY.com> wrote in
> message news:
>>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.
>>
> for(;;) is meaningless to anyone who doesn't know C,

Even assuming you meant "C or C-like languages", that's a bogus 
argument. x <<= y & ~z; is meaningless to anyone who doesn't know C, 
too. So?

> or even to
> someone with a reasonable but not extensive knowledge of the
> language. while(1) or while(true) is used by several programming
> lanauges to indicate infinite loops.

for(;;) is a perfectly good idiom which has the advantage of not 
triggering diagnostics in some compilers.

<snip>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

Lew Pitcher  <lew.pitcher@digitalfreehold.ca> wrote:
>On December 4, 2009 16:41, in comp.lang.c, Beej Jorgensen (beej@beej.us)
>>     repeat
>>         ...
>>     until false;
>> 
>  do
>    ...
>  while(1);
>
>which amounts to the same thing, doesn't it?

But it's far more true than false is! :-)

-Beej

Not Really Me wrote:
> 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?

No.

-- 
pete

Malcolm McLean wrote:

> for(;;) is meaningless to anyone who doesn't know C, 

C, is also meaningless to anyone who doesn't know C.

-- 
pete

On Fri, 04 Dec 2009 20:45:21 GMT, "bartc" <bartc@freeuk.com> wrote:

>>
>>    loop
>>        ...
>>    end loop;
>>
>> but that's not C either.
>
>No, that's a completely different syntax style and certainly not C.

It's actually pretty close to Fortran:

do
  ...
enddo

James Tursa

That's pretty funny Richard - for all your negative words about Antonius, 
you've just copied his post almost word for word!


/root


--
Learn more or lose your rights!
http://www.guncontrolkills.com/
http://www.gunbanobama.com/
Learn more or lose your rights!


Richard Heathfield wrote:
> In <pN6dna0jZtpNzYTWnZ2dnUVZ8jWdnZ2d@bt.com>, Malcolm McLean wrote:
> 
>> "Not Really Me" <scott@validatedQWERTYsoftware.XYZZY.com> wrote in
>> message news:
>>>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.
>>>
>> for(;;) is meaningless to anyone who doesn't know C,
> 
> Even assuming you meant "C or C-like languages", that's a bogus
> argument. x <<= y & ~z; is meaningless to anyone who doesn't know C,
> too. So?
> 
>> or even to
>> someone with a reasonable but not extensive knowledge of the language.
>> while(1) or while(true) is used by several programming lanauges to
>> indicate infinite loops.
> 
> for(;;) is a perfectly good idiom which has the advantage of not
> triggering diagnostics in some compilers.
> 
> <snip>

In <hfd95h$6hh$1@aioe.org>, root wrote:

> That's pretty funny Richard - for all your negative words about
> Antonius, you've just copied his post almost word for word!

It's hard to copy something you haven't seen. If he's actually said 
something sensible for a change, however, I suppose we should 
celebrate the novelty of the event.

<snip>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

On 04/12/2009 22:56, Curtis Dyer wrote:
> On 04 Dec 2009, "Malcolm McLean"<regniztar@btinternet.com>  wrote:
>
>> "Not Really Me"<scott@validatedQWERTYsoftware.XYZZY.com>  wrote
>> in message news:
>>> 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.
>>>
>> for(;;) is meaningless to anyone who doesn't know C,
>
> Why do you say that?  This construct works in PHP, Perl, ECMAScript,
> and probably other languages that have C-like for loops.

You are right, but it's not at all obvious what for(;;) might do. You 
have to look it up. It could easily be undefined behaviour or defined 
that the loop is skipped entirely.

Personally I use while(true) which is legible and obvious.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines
imposed, nor cruel and unusual punishments inflicted"

Bill of Rights 1689

"James Tursa" <aclassyguywithaknotac@hotmail.com> wrote in message 
news:oa8kh5t9m4vjg07t31d3m37o7tgaeusft5@4ax.com...
> On Fri, 04 Dec 2009 20:45:21 GMT, "bartc" <bartc@freeuk.com> wrote:
>
>>>
>>>    loop
>>>        ...
>>>    end loop;
>>>
>>> but that's not C either.
>>
>>No, that's a completely different syntax style and certainly not C.
>
> It's actually pretty close to Fortran:
>
> do
>  ...
> enddo

Fortran must have changed somewhat since the last time I used it (ie. 
version IV).

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

And I feel sure that the presence of the preprocessor in C has some 
responsibility for this, by providing a poor man's way of adding 'new' 
language constructs.

-- 
Bartc 

In <65Sdnd3_qqNPrYfWnZ2dnUVZ8qRi4p2d@brightview.co.uk>, Tim Streater 
wrote:

> On 04/12/2009 22:56, Curtis Dyer wrote:

<snip>
 
> You are right, but it's not at all obvious what for(;;) might do.
> You have to look it up. It could easily be undefined behaviour or
> defined that the loop is skipped entirely.
> 
> Personally I use while(true) which is legible and obvious.

I don't find for(;;) to be illegible, but I do find it AND while(true) 
to be deceptive unless the loop truly is infinite. Personally I use 
while(condition), which is legible, obvious, and accurate.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

On 05/12/2009 11:32, Richard Heathfield wrote:
> In<65Sdnd3_qqNPrYfWnZ2dnUVZ8qRi4p2d@brightview.co.uk>, Tim Streater
> wrote:
>
>> On 04/12/2009 22:56, Curtis Dyer wrote:
>
> <snip>
>
>> You are right, but it's not at all obvious what for(;;) might do.
>> You have to look it up. It could easily be undefined behaviour or
>> defined that the loop is skipped entirely.
>>
>> Personally I use while(true) which is legible and obvious.
>
> I don't find for(;;) to be illegible, but I do find it AND while(true)
> to be deceptive unless the loop truly is infinite.

I'm not saying its illegible, but to me a for-loop implies that a loop 
is going to run some predefined number of times, whereas a while-loop to 
me implies that there will be some break/exit condition within it.

> Personally I use while(condition), which is legible, obvious, and accurate.

Ah, you mean while(true==true) or perhaps while(false==false)  ??

<ducks and runs away>

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines
imposed, nor cruel and unusual punishments inflicted"

Bill of Rights 1689

"Tim Streater" <timstreater@waitrose.com> wrote in message 
news:1aOdndmK75zV0YfWnZ2dnUVZ8hydnZ2d@brightview.co.uk...
> On 05/12/2009 11:32, Richard Heathfield wrote:
>> In<65Sdnd3_qqNPrYfWnZ2dnUVZ8qRi4p2d@brightview.co.uk>, Tim Streater
>> wrote:
>>
>>> On 04/12/2009 22:56, Curtis Dyer wrote:
>>
>> <snip>
>>
>>> You are right, but it's not at all obvious what for(;;) might do.
>>> You have to look it up. It could easily be undefined behaviour or
>>> defined that the loop is skipped entirely.
>>>
>>> Personally I use while(true) which is legible and obvious.
>>
>> I don't find for(;;) to be illegible, but I do find it AND while(true)
>> to be deceptive unless the loop truly is infinite.
>
> I'm not saying its illegible, but to me a for-loop implies that a loop is 
> going to run some predefined number of times, whereas a while-loop to me 
> implies that there will be some break/exit condition within it.
>
>> Personally I use while(condition), which is legible, obvious, and 
>> accurate.
>
> Ah, you mean while(true==true) or perhaps while(false==false)  ??

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.

-- 
Bartc 

On  5 Dec 2009 at 13:00, bartc wrote:
> "Tim Streater" <timstreater@waitrose.com> wrote:
>> Ah, you mean while(true==true) or perhaps while(false==false)  ??
>
> 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".

On  5 Dec 2009 at  9:53, Richard Heathfield wrote:
> In <hfd95h$6hh$1@aioe.org>, root wrote:
>> That's pretty funny Richard - for all your negative words about
>> Antonius, you've just copied his post almost word for word!
>
> 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.

bartc wrote:
> [...]
> 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!

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

On 2009-12-04, Kaz Kylheku <kkylheku@gmail.com> wrote:
> 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.

-- 
Mr. Antti-Juhani Kaijanaho, Jyvaskyla, Finland

On Sat, 05 Dec 2009 09:57:06 -0500, Eric Sosman wrote:

> bartc wrote:
>> [...]
>> 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

Adrian Petrescu wrote:
> On Sat, 05 Dec 2009 09:57:06 -0500, Eric Sosman wrote:
> 
>> bartc wrote:
>>> [...]
>>> 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.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

On Sat, 05 Dec 2009 16:29:33 -0500, Eric Sosman wrote:
> 
>      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

Adrian Petrescu wrote:
> On Sat, 05 Dec 2009 16:29:33 -0500, Eric Sosman wrote:
>>      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.

     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
esosman@ieee-dot-org.invalid

In <1aOdndmK75zV0YfWnZ2dnUVZ8hydnZ2d@brightview.co.uk>, Tim Streater 
wrote:

> On 05/12/2009 11:32, Richard Heathfield wrote:
>> In<65Sdnd3_qqNPrYfWnZ2dnUVZ8qRi4p2d@brightview.co.uk>, Tim Streater
>> wrote:
>>
<snip>
>>>
>>> Personally I use while(true) which is legible and obvious.
>>
>> I don't find for(;;) to be illegible, but I do find it AND
>> while(true) to be deceptive unless the loop truly is infinite.
> 
> I'm not saying its illegible, but to me a for-loop implies that a
> loop is going to run some predefined number of times, whereas a
> while-loop to me implies that there will be some break/exit
> condition within it.

We obviously have very different ways of looking at while-loops. To 
me, a while loop implies that the loop will continue until its 
controlling condition becomes false; a break within the loop (and not 
within an inner switch or loop) confuses the issue somewhat - not in 
"obvious" code, but a lot of the breaks I've seen over the years have 
been non-obvious and poorly- or un-documented.

>> Personally I use while(condition), which is legible, obvious, and
>> accurate.
> 
> Ah, you mean while(true==true) or perhaps while(false==false)  ??

No, I mean, for example:

while(!done)
{
  done = stuff();
}

(which can be simplified, of course), or - if life's a little more 
complicated than that:

while(!done)
{
  pre_stuff();
  if(done = stuff())
  {
    post_stuff();
  }
}

which, presumably, you would write as:

while(1)
{
  pre_stuff();
  if(stuff())
    break;
  post_stuff();
}

> <ducks and runs away>

Runs away is easy:
chmod -x foo

I'm not so sure about ducks, though.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

In <5QsSm.12089$Ym4.9076@text.news.virginmedia.com>, bartc wrote:

> "Tim Streater" <timstreater@waitrose.com> wrote in message
> news:1aOdndmK75zV0YfWnZ2dnUVZ8hydnZ2d@brightview.co.uk...
>> On 05/12/2009 11:32, Richard Heathfield wrote:
<snip>
>>
>>> Personally I use while(condition), which is legible, obvious, and
>>> accurate.
>>
>> Ah, you mean while(true==true) or perhaps while(false==false)  ??
> 
> 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.

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.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

On Sat, 05 Dec 2009 16:29:33 -0500, Eric Sosman
<esosman@ieee-dot-org.invalid> wrote:

>
>     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;

True. They eventually formalized structs (user defined types in
Fortran lingo), dynamic memory allocation, and pointers (although a
Fortran pointer has type, base address, shape (number of dimensions
and extents of dimensions), and stride (are the dimensions contiguous
or interleaved in memory) information built in to the pointer), which
could be argued were inspired by other languages like C I suppose. And
Fortran has formalized iteroperability with C to make C/Fortran
inter-calling standardized. But Fortran also added a bunch of other
stuff making it fundamentally an array based language. Whole array
assignments, array slices used in calculations, automatically passing
array shapes in function calls, etc., are now all part of the
standard. This is quite a ways beyond what C has available when
working with arrays.

> should C
>respond by adding yet more constructs just so it can have
>bragging rights?

With Variable Length Arrays (VLA), it could be argued that C *has*
adopted something from other languages. Now, I don't really know what
the motivation was for VLA (other languages or just a general desire
to add useful functionality), but VLA is basically the same thing as
conformable arrays in Fortran which has been around for decades.

James Tursa

On 05/12/2009 23:08, Richard Heathfield wrote:
> In<1aOdndmK75zV0YfWnZ2dnUVZ8hydnZ2d@brightview.co.uk>, Tim Streater
> wrote:

>> I'm not saying its illegible, but to me a for-loop implies that a
>> loop is going to run some predefined number of times, whereas a
>> while-loop to me implies that there will be some break/exit
>> condition within it.
>
> We obviously have very different ways of looking at while-loops. To
> me, a while loop implies that the loop will continue until its
> controlling condition becomes false; a break within the loop (and not
> within an inner switch or loop) confuses the issue somewhat - not in
> "obvious" code, but a lot of the breaks I've seen over the years have
> been non-obvious and poorly- or un-documented.

Well, it depends. Typically when I write such a loop there may be 
several breaks depending on what has actually occurred, typically error 
conditions. If I'm reading text from the network and parsing it, I can 
have network errors, unexpected or incorrect text from the remote end, 
database errors while I try to save the text, ...

That is not amenable to a simple while (!done) { done=stuff(); } sort of 
construct.

>> <ducks and runs away>
>
> Runs away is easy:
> chmod -x foo
>
> I'm not so sure about ducks, though.

Foo Manchu, Ducky ??

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines
imposed, nor cruel and unusual punishments inflicted"

Bill of Rights 1689

Tim Streater wrote:
> On 05/12/2009 11:32, Richard Heathfield wrote:
> 
>> In<65Sdnd3_qqNPrYfWnZ2dnUVZ8qRi4p2d@brightview.co.uk>, Tim Streater
>> wrote:
>>
>>> On 04/12/2009 22:56, Curtis Dyer wrote:
>>
>>
>> <snip>
>>
>>> You are right, but it's not at all obvious what for(;;) might do.
>>> You have to look it up. It could easily be undefined behaviour or
>>> defined that the loop is skipped entirely.
>>>
>>> Personally I use while(true) which is legible and obvious.
>>
>>
>> I don't find for(;;) to be illegible, but I do find it AND while(true)
>> to be deceptive unless the loop truly is infinite.
> 
> 
> I'm not saying its illegible, but to me a for-loop implies that a loop 
> is going to run some predefined number of times, whereas a while-loop to 
> me implies that there will be some break/exit condition within it.

I definitely don't think of for loops that way.

unsigned bit_count(unsigned n)
{
     unsigned count;

     for (count = 0; n != 0; n &= n - 1) {
         ++count;
     }
     return count;
}

unsigned gray_to_binary(unsigned gray)
{
     unsigned binary;

     for (binary = 0; gray != 0; gray >>= 1) {
         binary ^= gray;
     }
     return binary;
}

-- 
pete

Richard Heathfield wrote:
> In <5QsSm.12089$Ym4.9076@text.news.virginmedia.com>, bartc wrote:
> 
>> "Tim Streater" <timstreater@waitrose.com> wrote in message
>> news:1aOdndmK75zV0YfWnZ2dnUVZ8hydnZ2d@brightview.co.uk...
>>> On 05/12/2009 11:32, Richard Heathfield wrote:
> <snip>
>>>> Personally I use while(condition), which is legible, obvious, and
>>>> accurate.
>>> Ah, you mean while(true==true) or perhaps while(false==false)  ??
>> 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.
> 
> 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?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

In <hff2bb$hom$1@news.eternal-september.org>, Eric Sosman wrote:

<snip>

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

Yes.

> Any results yet?

Not yet. Patience is a virtue. If you are prepared to increase the 
available budget, however, I may well be able to speed things up by a 
significant percentage.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

Tim Streater wrote:

> Well, it depends. Typically when I write such a loop there may be 
> several breaks depending on what has actually occurred, typically error 
> conditions. If I'm reading text from the network and parsing it, I can 
> have network errors, unexpected or incorrect text from the remote end, 
> database errors while I try to save the text, ...
> 
> That is not amenable to a simple while (!done) { done=stuff(); } sort of 
> construct.

In general I agree with Richard H. I try to avoid several exits from a 
block of code and try to stick with one return from a function. The 
reason is not that code following that style is easier to read but that 
it is easier to change. It also has the effect of making functions 
shorter to be able to do this. Because if a function does one thing and 
one thing only, then it reports on one thing as well.

If you have multiple fail conditions I would think that the above 
becomes while (status != DONE) { status=stuff(); } //check status here

I have never regretted following this style, but I have several times 
regretted not doing it.

-- 
Thomas.

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

Not Really Me wrote:

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

Michael Tsang wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Not Really Me wrote:
> 
>> 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.

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)
-- 
Flash Gordon

On 2009-12-05, Antti-Juhani Kaijanaho <antti-juhani@kaijanaho.fi> wrote:
> On 2009-12-04, Kaz Kylheku <kkylheku@gmail.com> wrote:
>> 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.

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.

Michael Tsang <miklcct@gmail.com> writes:
> Not Really Me wrote:
>> 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.

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.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

"Kaz Kylheku" <kkylheku@gmail.com> wrote in message 
news:20091206073324.128@gmail.com...
> On 2009-12-05, Antti-Juhani Kaijanaho <antti-juhani@kaijanaho.fi> wrote:
>> On 2009-12-04, Kaz Kylheku <kkylheku@gmail.com> wrote:
>>> 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.
>
> Oh goodie! Just what we need, double semicolon!

Yeah.

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

-- 
Bartc

"bartc" <bartc@freeuk.com> wrote in message news:
>
> 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.
>
You can have only one infinite loop in a program.
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.

Malcolm McLean wrote:
> "bartc" <bartc@freeuk.com> wrote in message news:
>> 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.
>>
> 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.
-- 
Flash Gordon

"Malcolm McLean" <regniztar@btinternet.com> wrote in message 
news:7_OdnZwIpYCKqYHWnZ2dnUVZ8uednZ2d@bt.com...
> "bartc" <bartc@freeuk.com> wrote in message news:
>>
>> 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.
>>
> 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?




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

In <7_OdnZwIpYCKqYHWnZ2dnUVZ8uednZ2d@bt.com>, Malcolm McLean wrote:

<snip>

> If there is some (non-external) condition that terminates the loop,
> generally it should be in the condition that controls it.

Right, but it's a style thing. Not everyone agrees with us.

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

See? Even you disagree with us.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

On 5 Dec, 21:01, Adrian Petrescu <apetr...@gmail.com> wrote:
> On Sat, 05 Dec 2009 09:57:06 -0500, Eric Sosman wrote:
> > bartc wrote:


> >> But that brings up an interesting point: some languages seem happy to
> >> evolve and to embrace new syntax, but some, like C, don't.
>
> > =A0 =A0 =A0For some reason (my aging eyesight, perhaps), I'm having
> > trouble finding function prototype syntax described in my copy of K&R
> > Classic. =A0Would you mind telling me which pages cover it?
>
> > =A0 =A0 =A0It would be nice if you'd also point me to the description
> > of `...' variable-argument syntax.
>
> 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"?

On 5 Dec, 13:00, "bartc" <ba...@freeuk.com> wrote:
> "Tim Streater" <timstrea...@waitrose.com> wrote in message
>
> news:1aOdndmK75zV0YfWnZ2dnUVZ8hydnZ2d@brightview.co.uk...
>
>
>
>
>
> > On 05/12/2009 11:32, Richard Heathfield wrote:
> >> In<65Sdnd3_qqNPrYfWnZ2dnUVZ8qRi4...@brightview.co.uk>, Tim Streater
> >> wrote:
> >>> On 04/12/2009 22:56, Curtis Dyer wrote:


> >>> You are right, but it's not at all obvious what for(;;) might do.

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

> >>> You have to look it up. It could easily be undefined behaviour or
> >>> defined that the loop is skipped entirely.
>
> >>> Personally I use while(true) which is legible and obvious.
>
> >> I don't find for(;;) to be illegible, but I do find it AND while(true)
> >> to be deceptive unless the loop truly is infinite.
>
> > I'm not saying its illegible, but to me a for-loop implies that a loop =
is
> > going to run some predefined number of times,

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


> > whereas a while-loop to me
> > implies that there will be some break/exit condition within it.
>
> >> Personally I use while(condition), which is legible, obvious, and
> >> accurate.
>
> > Ah, you mean while(true=3D=3Dtrue) or perhaps while(false=3D=3Dfalse) =
=A0??
>
> 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.

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
> On 5 Dec, 21:01, Adrian Petrescu <apetr...@gmail.com> wrote:
[...]
>> 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!

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.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On 7 Dec, 08:23, Keith Thompson <ks...@mib.org> wrote:
> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
> > On 5 Dec, 21:01, Adrian Petrescu <apetr...@gmail.com> wrote:
> [...]
> >> If, as it seems, you are sarcastically implying that two urgently-need=
ed
> >> 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 t=
han
> >> 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!
>
> K&R1 was published, if I recall correctly, in 1978, 31 years ago. =A0If
> 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.

In 
<4fa9ab82-6dcd-4c4b-b95d-dc49b8cc505c@g23g2000vbr.googlegroups.com>, 
Nick Keighley wrote:

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

"self-terminate" might be a useful term to invent at this point. We 
could define a self-terminating program as one which can terminate 
simply by following the rules of the language. Thus, this program is 
self-terminating:

#include <stdio.h>

int main(void)
{
  int ch;
  while((ch = getchar()) != EOF)
  {
    continue;
  }
  return 0;
}

because, at least in theory, it is possible for the program logic to 
reach one of C's ways of terminating the program (exit() and return 
from main() being the most important, though there is at least one 
more), even though it might be sat waiting for the stream, and even 
though the stream might simply be piped from:

#include <stdio.h>

int main(void)
{
  for(;;)
  {
    putchar('\n');
  }
  return 0;
}

(which is not self-terminating).

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

On Dec 5, 2:02=A0pm, James Tursa <aclassyguywithakno...@hotmail.com>
wrote:
> On Fri, 04 Dec 2009 20:45:21 GMT, "bartc" <ba...@freeuk.com> wrote:
>
> >> =A0 =A0loop
> >> =A0 =A0 =A0 =A0...
> >> =A0 =A0end loop;
>
> >> but that's not C either.
>
> >No, that's a completely different syntax style and certainly not C.
>
> It's actually pretty close to Fortran:
>
> do
> =A0 ...
> enddo
>
> James Tursa

I think that both are same, either you go with for(;;) or while(1).
But i guess, on the internal workings, while(1) is far better than for
(;;) [ even though, for(;;) is cleaner to read ]. The reason being,
while implementing the for(;;), the code has to maintain an internal
variable, for incrementing it and checking for infinity [ Correct me
if am wrong ], whereas in the case of while(1), its just a flag check
and nothing more.

So, i would prefer to use while(1) than for(;;), at the cost of the
readability.

Roopesh.

"James" <no@spam.invalid> wrote in message
> "Malcolm McLean" <regniztar@btinternet.com> wrote in message
>> "bartc" <bartc@freeuk.com> wrote in message news:
>>>
>>> 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.
>>>
>> 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?
>
You're right. I nodded.
It's very common to see programs which do a bit of set up, then enter an 
infinite loop (a typical one is a message loop from a GUI). However you 
could have a program with two or more infinite loops which switches between 
them depending on conditions. You could even (though rarely) have the first 
infinite loop broken by an external signal, and then enter the second.

In 
<7b0146a3-f705-467c-a5a7-493866d1ea6b@r24g2000prf.googlegroups.com>, 
Roopesh wrote:

<snip>

> I think that both are same, either you go with for(;;) or while(1).
> But i guess, on the internal workings, while(1) is far better than
> for (;;) [ even though, for(;;) is cleaner to read ]. The reason
> being, while implementing the for(;;), the code has to maintain an
> internal variable, for incrementing it and checking for infinity [
> Correct me if am wrong ],

You're wrong. The compiler is under no such obligation.

> whereas in the case of while(1), its just
> a flag check and nothing more.

Not even that. Both for(;;) and while(1) can be implemented as:

:label
stuff
jmp label

> So, i would prefer to use while(1) than for(;;), at the cost of the
> readability.

If that's your only reason, you can now revert to for(;;).

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

"Malcolm McLean" <regniztar@btinternet.com> wrote in message 
news:9d6dnQ2PmuEcVYHWnZ2dnUVZ8ludnZ2d@bt.com...
> "James" <no@spam.invalid> wrote in message
>> "Malcolm McLean" <regniztar@btinternet.com> wrote in message
>>> "bartc" <bartc@freeuk.com> wrote in message news:
>>>>
>>>> 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.
>>>>
>>> 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?
>>
> You're right. I nodded.
> It's very common to see programs which do a bit of set up, then enter an 
> infinite loop (a typical one is a message loop from a GUI). However you 
> could have a program with two or more infinite loops which switches 
> between them depending on conditions. You could even (though rarely) have 
> the first infinite loop broken by an external signal, and then enter the 
> second.

I used infinite loop to mean one which uses an explicit break somewhere in 
the body.

I use them all the time, mainly because when I start to write one, I have 
little idea how I'm going to jump out it. And later I don't bother to change 
it to conventional form.

-- 
Bartc

"bartc" <bartc@freeuk.com> wrote in message >
>
> I used infinite loop to mean one which uses an explicit break somewhere in 
> the body.
>
In my usage, an infinite loop is something like

while(1)
{
   tick();
   waitforframesynch();
}

you see this type of thing quite a lot. In this case, the program has to 
draw something to the screen  every frame, so the outer loop imposes that 
condition. It won't terminate until the prgram itself is terminated (often 
by the device being powered down).

>
> I use them all the time, mainly because when I start to write one, I have 
> little idea how I'm going to jump out it. And later I don't bother to 
> change it to conventional form.
>
If you terminate when game over, I'd write the loop

while( ! gameover() )
{
   tick();
   waitforframesynch();
}

this

while(1)
{
   tick();
   if(gameover())
     break;
   watiforframesynch();
}

is in my opinion sloppy.

However this

int gameflag = 1;

while(gameflag)
{
   tick();
   if(gameover())
     gameflag = 0;
  waitforframesynch();
}

is in my opinion worse, because you are creating an artificial bit of logic.

(As always with programming little snippets don't really show the issue. Any 
short section of code is readily understandable. The problems come when the 
loop control is buried in complicated non-loop instructions). 

Flash Gordon wrote:
> Malcolm McLean wrote:
>> "bartc" <bartc@freeuk.com> wrote in message news:
>>> 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.
>>>
>> 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. [...]

	for (;;) {
	    while (1) {
	        do {
	            otog:
	                ...
	            goto otog;
	        } while (1);
	    }
	}

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

On 7 Dec, 10:52, "bartc" <ba...@freeuk.com> wrote:
> "Malcolm McLean" <regniz...@btinternet.com> wrote in message
> news:9d6dnQ2PmuEcVYHWnZ2dnUVZ8ludnZ2d@bt.com...
> > "James" <n...@spam.invalid> wrote in message
> >> "Malcolm McLean" <regniz...@btinternet.com> wrote in message
> >>> "bartc" <ba...@freeuk.com> wrote in message news:

<snip>

> >>> You can have only one infinite loop in a program.

<snip>

> I used infinite loop to mean one which uses an explicit break somewhere in
> the body.

whilst other people use it to mean a loop that *never* terminates.
I've probably described for(;;) as "an infinite loop" even when I've
been sure it does terminate. But that is a a bit sloppy.

> I use them all the time, mainly because when I start to write one, I have
> little idea how I'm going to jump out it.

eeek! How can you write a loop without knowing how it will terminate!
Surely you construct the loop-invarient and termination criteria
*before* you write the loop!
:-)

> And later I don't bother to change
> it to conventional form.

I use the construct when none of the normal C-loop forms will do. That
is I want to break out of the middle of the loop. You can use an extra
boolean variable but sometimes that seems contrived.

   for (;;)
   {
        skip_leading_whitespace (stream);

        if (!build_msg (msg, stream))
            break;                      /* <-- break out of loop */

       process_msg (msg);
   }

bartc wrote:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnaaxyxzzq.fsf@nuthaus.mib.org...
>> "bartc" <bartc@freeuk.com> writes:
>> [...]
>>> While we're talking about aesthetics, then both for() and while()
>>> are cleaner.
>>>
>>> There's a condition missing from the while statement, but then
>>> there's also one missing from the for(;;).
>>
>> If you mean literally "for()" and "while()", I hardly think that the
>> aesthetics of code that won't compile is relevant.
>
> That's a minor detail. I don't think allowing an empty condition on
> while(), to match the empty one in for(;;), or taking those two
> semicolons as read (since they are not separating or terminating
> anything), is too taxing for compiler maintainers.
>
> (And for all I know, extensions might already exist for those.)
>
>>  I personally like
>>
>>    loop
>>        ...
>>    end loop;
>>
>> but that's not C either.
>
> No, that's a completely different syntax style and certainly not C.
> I'm talking about being allowed to leave out one or two characters
> which don't contribute anything.

Aargh!  Sorry but I was hoping for "valid" reaons.  In C99, the conditions 
are stated as optional in a for statement, but they are mandatory for while.

-- 
Scott
Validated Software
Lafayette, CO 



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4667 (20091207) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Beej Jorgensen wrote:
> bartc <bartc@freeuk.com> wrote:
>> While we're talking about aesthetics, then both for() and while() are
>> cleaner.
>
> Sorry for the digression, but:
>
> Using Pascal in college, my friend liked to use the significantly
> less-clean:
>
>    repeat
>        ...
>    until false;
>
> which always made me giggle.
>
> -Beej

That's as bad as my friend who liked:

#define WahDiddy     while(1)

do {
     ...
} WahDiddy;

Maybe you had to grow up in the sixties here in the US.

>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4667 (20091207) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com 



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4667 (20091207) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

pete wrote:
> Not Really Me wrote:
>> 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?
>
> No.

Thanks Pete.  Best answer of the bunch.  It is what I expected, but I needed 
to ask.

-- 
Scott
Validated Software
Lafayette, CO 



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4667 (20091207) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

James wrote:
[...]
> #define FOREVER for (;;)
> 
> 
> void foo()
> {
>    FOREVER
>    {
>        /* [...] */
>    }
> }
> 

ITYM:

#define ever (;;)

void foo()
     {
     for ever
         {
         /* ... */
         }
     }

> lol! I could not resist.

Ditto.

-- 
Kenneth Brody

Richard Heathfield wrote:
[...]
> I don't find for(;;) to be illegible, but I do find it AND while(true) 
> to be deceptive unless the loop truly is infinite. Personally I use 
> while(condition), which is legible, obvious, and accurate.

"while (!done)" is common for me for loops that have more than one "obvious" 
terminal condition.

-- 
Kenneth Brody

Tim Streater wrote:
> On 05/12/2009 23:08, Richard Heathfield wrote:
>> In<1aOdndmK75zV0YfWnZ2dnUVZ8hydnZ2d@brightview.co.uk>, Tim Streater
>> wrote:
> 
>>> I'm not saying its illegible, but to me a for-loop implies that a
>>> loop is going to run some predefined number of times, whereas a
>>> while-loop to me implies that there will be some break/exit
>>> condition within it.
>>
>> We obviously have very different ways of looking at while-loops. To
>> me, a while loop implies that the loop will continue until its
>> controlling condition becomes false; a break within the loop (and not
>> within an inner switch or loop) confuses the issue somewhat - not in
>> "obvious" code, but a lot of the breaks I've seen over the years have
>> been non-obvious and poorly- or un-documented.
> 
> Well, it depends. Typically when I write such a loop there may be 
> several breaks depending on what has actually occurred, typically error 
> conditions. If I'm reading text from the network and parsing it, I can 
> have network errors, unexpected or incorrect text from the remote end, 
> database errors while I try to save the text, ...
> 
> That is not amenable to a simple while (!done) { done=stuff(); } sort of 
> construct.
[...]

How do you feel about "continue"?

while (!done)
     {
     done = stuff();
     if (done)
         continue;
     done = more_stuff();
     }

Pretty lame, I admit.  I suppose "continue" could be thought of as "goto in 
disguise"?

-- 
Kenneth Brody

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
> On 7 Dec, 08:23, Keith Thompson <ks...@mib.org> wrote:
>> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
>> > On 5 Dec, 21:01, Adrian Petrescu <apetr...@gmail.com> wrote:
>> [...]
>> >> 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!
>>
>> 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.

I think Adrian's point was that significant new syntax (prototypes and
"...") was added once in that 31/32 year period (the C99 syntax
changes were relatively minor).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Roopesh wrote:
> On Dec 5, 2:02 pm, James Tursa <aclassyguywithakno...@hotmail.com>
> wrote:
>> On Fri, 04 Dec 2009 20:45:21 GMT, "bartc" <ba...@freeuk.com> wrote:
>>
>>>>    loop
>>>>        ...
>>>>    end loop;
>>>> but that's not C either.
>>> No, that's a completely different syntax style and certainly not C.
>> It's actually pretty close to Fortran:
>>
>> do
>>   ...
>> enddo
>>
>> James Tursa
> 
> I think that both are same, either you go with for(;;) or while(1).

Yes.

> But i guess, on the internal workings, while(1) is far better than for
> (;;)

No. I would say the reverse.

> [ even though, for(;;) is cleaner to read ]. The reason being,
> while implementing the for(;;), the code has to maintain an internal
> variable, for incrementing it and checking for infinity [ Correct me
> if am wrong ],

You are wrong. C for loops to not rely on a loop counter even 
conceptually. for (;;) reads...
    Do no initialiastion
    {
       Do not check a condition
       Do loop body
       Do not do anything for moving on to the next iteration
    }
So the for loop is saying explicitly that you do not have a condition.

In C, if you want a conceptual loop counter you have to explicitly 
provide it.

> whereas in the case of while(1), its just a flag check
> and nothing more.

True.

> So, i would prefer to use while(1) than for(;;), at the cost of the
> readability.

Well, your reasoning is wrong. In any case, the compiler can implement 
it with an unconditional jump, and I've yet to see one that implements a 
test.
-- 
Flash Gordon

Flash Gordon <smap@spam.causeway.com> writes:

> Roopesh wrote:
>> On Dec 5, 2:02 pm, James Tursa <aclassyguywithakno...@hotmail.com>
>> wrote:
>>> On Fri, 04 Dec 2009 20:45:21 GMT, "bartc" <ba...@freeuk.com> wrote:
>>>
>>>>>    loop
>>>>>        ...
>>>>>    end loop;
>>>>> but that's not C either.
>>>> No, that's a completely different syntax style and certainly not C.
>>> It's actually pretty close to Fortran:
>>>
>>> do
>>>   ...
>>> enddo
>>>
>>> James Tursa
>> 
>> I think that both are same, either you go with for(;;) or while(1).
>
> Yes.
>
>> But i guess, on the internal workings, while(1) is far better than for
>> (;;)
>
> No. I would say the reverse.
>
>> [ even though, for(;;) is cleaner to read ]. The reason being,
>> while implementing the for(;;), the code has to maintain an internal
>> variable, for incrementing it and checking for infinity [ Correct me
>> if am wrong ],
>
> You are wrong. C for loops to not rely on a loop counter even 
> conceptually. 

You are wrong. Most/a huge percentage of  C for loops do indeed rely on
a loop counter.

On Dec 4, 1:06=A0pm, "Not Really Me"
<sc...@validatedQWERTYsoftware.XYZZY.com> wrote:
> 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 warnin=
gs,
> 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.
>
> --
> Scott
> Validated Software
> Lafayette, CO
>
> __________ Information from ESET NOD32 Antivirus, version of virus signat=
ure database 4661 (20091204) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com

A bit silly perhaps but I like the following:

Use the preprocessor directive

#define EVER ;;

then you can use

for(EVER)
{
  stuff
}

for the infinite loop

Richard wrote:
> Flash Gordon <smap@spam.causeway.com> writes:
> 
>> Roopesh wrote:
>>> On Dec 5, 2:02 pm, James Tursa <aclassyguywithakno...@hotmail.com>
>>> wrote:
>>>> On Fri, 04 Dec 2009 20:45:21 GMT, "bartc" <ba...@freeuk.com> wrote:
>>>>
>>>>>>    loop
>>>>>>        ...
>>>>>>    end loop;
>>>>>> but that's not C either.
>>>>> No, that's a completely different syntax style and certainly not C.
>>>> It's actually pretty close to Fortran:
>>>>
>>>> do
>>>>   ...
>>>> enddo
>>>>
>>>> James Tursa
>>> I think that both are same, either you go with for(;;) or while(1).
>> Yes.
>>
>>> But i guess, on the internal workings, while(1) is far better than for
>>> (;;)
>> No. I would say the reverse.
>>
>>> [ even though, for(;;) is cleaner to read ]. The reason being,
>>> while implementing the for(;;), the code has to maintain an internal
>>> variable, for incrementing it and checking for infinity [ Correct me
>>> if am wrong ],
>> You are wrong. C for loops to not rely on a loop counter even 
>> conceptually. 
> 
> You are wrong. Most/a huge percentage of  C for loops do indeed rely on
> a loop counter.

You missunderstood me. The C for loop does not rely on a loop counter. 
Of course, many loops make use of a loop counter, and as I stated, but 
you snipped without marking the snippage, when you use a loop counter 
you have to do so explicitly.

It is also clear from what the OP posted what I was refuting.
-- 
Flash Gordon

In 
<53abc6bd-e353-421f-940b-3ba0620f188b@z35g2000prh.googlegroups.com>, 
scattered wrote:

<snip>
 
> A bit silly perhaps but I like the following:
> 
> Use the preprocessor directive
> 
> #define EVER ;;

This macro invades space reserved by the Standard for future 
expansion. This is perhaps unlikely to cause a problem, although it's 
not beyond the bounds of possibility that some future C Standard 
might define EVER as an error code (wrong version of Windows, 
mayhap?).

<snip>

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

scattered wrote:
> 
> A bit silly perhaps but I like the following:
> 
> Use the preprocessor directive
> 
> #define EVER ;;
> 
> then you can use
> 
> for(EVER)
> {
>   stuff
> }
> 
> for the infinite loop

     When I was young and stupid, I used to write

	#define until(x) while(!(x))

so I could have `do { something } until(condition);'.  It took
me a while to understand that this made my code *less* readable
rather than more, because the reader encountering the latter had
to stop and go hunt for the definition of `until'.  Interrupting
the reader's train of thought was not helpful.

     Somebody handed down a Commandment along the lines of "Thou
shalt not use the preprocessor to muck up the syntax," but I
can't find the original and don't know the identity of the God
whose command it was.  Personally, I think it must have been a
false God, because every so often one comes across an inspired
use that *does* do violence to the syntax, and does it for a
good reason.  But things like `until' and `EVER' are just silly;
"beautiful new impediments to understanding" as the real, true
Ten Commandments puts it.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

>     Somebody handed down a Commandment along the lines of "Thou
> shalt not use the preprocessor to muck up the syntax," but I
> can't find the original and don't know the identity of the God
> whose command it was.  Personally, I think it must have been a
> false God, because every so often one comes across an inspired
> use that *does* do violence to the syntax, and does it for a
> good reason.  But things like `until' and `EVER' are just silly;
> "beautiful new impediments to understanding" as the real, true
> Ten Commandments puts it.

My favorite additions to syntax are macros that allow one to
iterate over a custom data structure without manually writing out
extensive "for (...)" syntax.
-- 
"IMO, Perl is an excellent language to break your teeth on"
--Micah Cowan

"Not Really Me" <scott@validatedQWERTYsoftware.XYZZY.com> a �crit dans le 
message de news: 7o4kd2F3p4qagU1@mid.individual.net...
> pete wrote:
>> Not Really Me wrote:
>>> 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?
>>
>> No.
>
> Thanks Pete.  Best answer of the bunch.  It is what I expected, but I 
> needed to ask.

Actually, there is one technical reason that has not been mentioned yet... 
Funny it took pete's blunt answer to make me remember it:

for(;;) is a blunt, obvious looping contruct.

while(1) on the other hand can be confused with while(l)

this is imho a good reason to avoid both while(1) and local variables named 
l

-- 
Chqrlie. 

"Charlie Gordon" <news@chqrlie.org> writes:
> "Not Really Me" <scott@validatedQWERTYsoftware.XYZZY.com> a écrit dans le 
> message de news: 7o4kd2F3p4qagU1@mid.individual.net...
>> pete wrote:
>>> Not Really Me wrote:
>>>> 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?
>>>
>>> No.
>>
>> Thanks Pete.  Best answer of the bunch.  It is what I expected, but I 
>> needed to ask.
>
> Actually, there is one technical reason that has not been mentioned yet... 
> Funny it took pete's blunt answer to make me remember it:
>
> for(;;) is a blunt, obvious looping contruct.
>
> while(1) on the other hand can be confused with while(l)
>
> this is imho a good reason to avoid both while(1) and local variables named 
> l

Interesting.

I've seen the visual similarity of the digit '1' and the letter
'l' presented as a reason (and a very good one IMHO) to avoid using
'l' as an identifier.  I've never seen it presented as a reason to
avoid using the number 1.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

"Charlie Gordon" <news@chqrlie.org> writes:

> "Not Really Me" <scott@validatedQWERTYsoftware.XYZZY.com> a écrit dans le 
> message de news: 7o4kd2F3p4qagU1@mid.individual.net...
>> pete wrote:
>>> Not Really Me wrote:
>>>> 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?
>>>
>>> No.
>>
>> Thanks Pete.  Best answer of the bunch.  It is what I expected, but I 
>> needed to ask.
>
> Actually, there is one technical reason that has not been mentioned yet... 
> Funny it took pete's blunt answer to make me remember it:
>
> for(;;) is a blunt, obvious looping contruct.
>
> while(1) on the other hand can be confused with while(l)
>
> this is imho a good reason to avoid both while(1) and local variables named 
> l

Crikey, do you also avoid using the integer 1 in case people confuse
it for l?

I really can't think of a worse reason not for using while(1). What font
do you use? my "1" looks nothing like an "l".

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

On December 7, 2009 20:16, in comp.lang.c, Charlie Gordon (news@chqrlie=
..org)
wrote:

> "Not Really Me" <scott@validatedQWERTYsoftware.XYZZY.com> a =C3=A9cri=
t dans le
> message de news: 7o4kd2F3p4qagU1@mid.individual.net...
>> pete wrote:
>>> Not Really Me wrote:
>>>> 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?
>>>
>>> No.
>>
>> Thanks Pete.  Best answer of the bunch.  It is what I expected, but =
I
>> needed to ask.
>=20
> Actually, there is one technical reason that has not been mentioned y=
et...
> Funny it took pete's blunt answer to make me remember it:
>=20
> for(;;) is a blunt, obvious looping contruct.
>=20
> while(1) on the other hand can be confused with while(l)

So? Instead of a constant 1, the programmer /could/ use any other non-z=
ero
integral value. Thus
  while (2)
is just as effective, and few people would confuse a 2 with a C identif=
ier.

But, perhaps even better (from the readability point of view) would be =
to
use a tautology
  while (1 =3D=3D 1)
or
  while (7 !=3D 6)
accomplishes the same thing, but with an obvious "truth" value


> this is imho a good reason to avoid both while(1) and local variables=

> named l
>=20

Having said all that, I prefer
  for (;;)
over
  while (1)

The programmer / reader has to evaluate the condition in the while () l=
oop
and determine if it will always evaluate to true. Trivial for while (1)=
 or
while (0), but not so trivial for other conditions. OTOH, the for (;;)
template leaves the reader/programmer with nothing to evaluate; if they=
 see
no terminating condition, the loop doesn't terminate.

I know that these are trivial reasons, but that's how /I/ make my choic=
e as
to which looping construct I'll use for infinite loops. Heck, it could =
be
worse. I /could/ use
  some_label:;
           /**/
           goto some_label;
=20

:-)
--=20
Lew Pitcher
Master Codewright & JOAT-in-training   | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.c=
a/
----------      Slackware - Because I know what I'm doing.         ----=
--

On Dec 7, 5:34=A0pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> scattered wrote:
>
> > A bit silly perhaps but I like the following:
>
> > Use the preprocessor directive
>
> > #define EVER ;;
>
> > then you can use
>
> > for(EVER)
> > {
> > =A0 stuff
> > }
>
> > for the infinite loop
>
> =A0 =A0 =A0When I was young and stupid, I used to write
>
> =A0 =A0 =A0 =A0 #define until(x) while(!(x))
>
> so I could have `do { something } until(condition);'. =A0It took
> me a while to understand that this made my code *less* readable
> rather than more, because the reader encountering the latter had
> to stop and go hunt for the definition of `until'. =A0Interrupting
> the reader's train of thought was not helpful.
>
> =A0 =A0 =A0Somebody handed down a Commandment along the lines of "Thou
> shalt not use the preprocessor to muck up the syntax," but I
> can't find the original and don't know the identity of the God
> whose command it was. =A0Personally, I think it must have been a
> false God, because every so often one comes across an inspired
> use that *does* do violence to the syntax, and does it for a
> good reason. =A0But things like `until' and `EVER' are just silly;
> "beautiful new impediments to understanding" as the real, true
> Ten Commandments puts it.
>
> --
> Eric Sosman
> esos...@ieee-dot-org.invalid- Hide quoted text -
>
> - Show quoted text -

Good advice - it's not like the idiom for(;;){...} is that hard to
understand. On the other hand, I am basically a hobby programmer who
doesn't forsee my code ever being read let alone maintained by others,
so sometimes I adopt little idiosyncratic conventions for my own use.

On 7 Dec, 16:15, Keith Thompson <ks...@mib.org> wrote:
> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:

> > 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.
>
> I think Adrian's point was that significant new syntax (prototypes and
> "...") was added once in that 31/32 year period (the C99 syntax
> changes were relatively minor).

designated initialisers?

On 8 Dec, 01:24, Keith Thompson <ks...@mib.org> wrote:
> "Charlie Gordon" <n...@chqrlie.org> writes:
> > "Not Really Me" <sc...@validatedQWERTYsoftware.XYZZY.com> a =E9crit dan=
s le
> > message denews: 7o4kd2F3p4qa__BEGIN_MASK_n#9g02mG7!__...__END_MASK_i?a6=
3jfAD$z__@mid.individual.net...
> >> pete wrote:
> >>> Not Really Me wrote:
> >>>> 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?
>
> >>> No.
>
> >> Thanks Pete. =A0Best answer of the bunch. =A0It is what I expected, bu=
t I
> >> needed to ask.
>
> > Actually, there is one technical reason that has not been mentioned yet=
....
> > Funny it took pete's blunt answer to make me remember it:
>
> > for(;;) is a blunt, obvious looping contruct.
>
> > while(1) on the other hand can be confused with while(l)
>
> > this is imho a good reason to avoid both while(1) and local variables n=
amed
> > l
>
> Interesting.
>
> I've seen the visual similarity of the digit '1' and the letter
> 'l' presented as a reason (and a very good one IMHO) to avoid using
> 'l' as an identifier. =A0I've never seen it presented as a reason to
> avoid using the number 1.

1 (one) is one of the few numeric constants I allow in my code. 0
(zero) being the other one. Oh, ok some masks might sneak in.

On 8 Dec, 03:28, scattered <still.scatte...@gmail.com> wrote:

> Good advice - it's not like the idiom for(;;){...} is that hard to
> understand. On the other hand, I am basically a hobby programmer who
> doesn't forsee my code ever being read let alone maintained by others,
> so sometimes I adopt little idiosyncratic conventions for my own use.

eventually though you become "the other".

Believe me, some of your old code will eventually look very odd to
you!

On Dec 8, 6:17=A0am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 8 Dec, 03:28, scattered <still.scatte...@gmail.com> wrote:
>
> > Good advice - it's not like the idiom for(;;){...} is that hard to
> > understand. On the other hand, I am basically a hobby programmer who
> > doesn't forsee my code ever being read let alone maintained by others,
> > so sometimes I adopt little idiosyncratic conventions for my own use.
>
> eventually though you become "the other".
>
> Believe me, some of your old code will eventually look very odd to
> you!

Oh, I believe you. I've already had cases where I ended up rewriting
from scratch a program that I had intended to merely modify bacause it
seemed easier than trying to figure out what the earlier program was
actually doing. So I do use things like comments and descriptive
variable names much more than I strictly need to. I no longer use my
EVER macro (mostly because of laziness rather than concern for long-
term readability - it's more typing) but thought it still somewhat
amusing.

In one of my more demented moments I wrote a program in Visual Basic
that used a boolean variable FatLadySings in the construct Do ... Loop
Until FatLadySings. It was part of a simulation of the child's game
CandyLand, so I was in a frivolous mood.

On 2009-12-06, Kaz Kylheku <kkylheku@gmail.com> wrote:
> On 2009-12-05, Antti-Juhani Kaijanaho <antti-juhani@kaijanaho.fi> wrote:
>> 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 */

Mm.  I said "after the block", not "after the statement".  But good point, I
forgot C allows a single statement in that position.

-- 
Mr. Antti-Juhani Kaijanaho, Jyvaskyla, Finland

On 8 Dec, 12:09, scattered <still.scatte...@gmail.com> wrote:

> In one of my more demented moments I wrote a program in Visual Basic
> that used a boolean variable FatLadySings in the construct Do ... Loop
> Until FatLadySings. It was part of a simulation of the child's game
> CandyLand, so I was in a frivolous mood.

#ifdef HELL_FROZEN
    ... some ifdef'd out code ...
#endif

Keith Thompson <kst-u@mib.org> writes:
>("while(1)" might be clearer than "for(;;)" to someone who doesn't
>know C very well, but I wouldn't worry about that.)

  This would be a reason in favor of �for(;;)� (I do not want
  someone who doesn't know C well to review my code, so I hope
  that it would keep such reviewers out or at least make life
  harder for them.)

Keith Thompson <kst-u@mib.org> writes:
>Actually, it's Ada.  In this context, "loop" is like C's "while (1) {",

      �#define LOOP	for(;;){
      #define POOL	}�

    S. R. Bourne, 1979-01-12

http://minnie.tuhs.org/UnixTree/V7/usr/src/cmd/sh/mac.h.html

  (I used to "remember" that he called it "FOREVER", but my
  memory seems to have been wrong.)

Kaz Kylheku <kkylheku@gmail.com> writes:
>do S ;  /* semicolon required to denote infinite looping over S */
>Now let S be the statement ``do { } while(condition); '' and we get:

  The semicolon is required only in your phantasy.

  ISO/IEC 9899:1999 (E) reads:

do statement while ( expression ) ;

  There is no �;� after �statement�.

In <semicolon-20091209113851@ram.dialup.fu-berlin.de>, Stefan Ram 
wrote:

> Kaz Kylheku <kkylheku@gmail.com> writes:
>>do S ;  /* semicolon required to denote infinite looping over S */
>>Now let S be the statement ``do { } while(condition); '' and we get:
> 
>   The semicolon is required only in your phantasy.
> 
>   ISO/IEC 9899:1999 (E) reads:
> 
> do statement while ( expression ) ;
> 
>   There is no �;� after �statement�.

Try telling your compiler that.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

Charlie Gordon wrote:
> "Not Really Me" <scott@validatedQWERTYsoftware.XYZZY.com> a �crit
> dans le message de news: 7o4kd2F3p4qagU1@mid.individual.net...
>> pete wrote:
>>> Not Really Me wrote:
>>>> 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?
>>>
>>> No.
>>
>> Thanks Pete.  Best answer of the bunch.  It is what I expected, but I
>> needed to ask.
>
> Actually, there is one technical reason that has not been mentioned
> yet... Funny it took pete's blunt answer to make me remember it:
>
> for(;;) is a blunt, obvious looping contruct.
>
> while(1) on the other hand can be confused with while(l)
>
> this is imho a good reason to avoid both while(1) and local variables
> named l

Putting on my Dilbert Dinosaur costume...  Back in the early 80's I was a 
one person consulting business.  I finally hired a "receptionist/assitant". 
She was a returning to work mother with grown kids.  The first task I gave 
her was to type an old basic program into the computer.  You quessed?  She 
used lower case 'l' instead of 1 throughout the program.  I was using 
CBasic, so the code was entered in an editor, not a live basic interpreter. 
Aargh!

-- 
Scott
Validated Software
Lafayette, CO 



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4673 (20091209) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

"Not Really Me" <scott@validatedQWERTYsoftware.XYZZY.com> writes:

> Charlie Gordon wrote:
>> "Not Really Me" <scott@validatedQWERTYsoftware.XYZZY.com> a écrit
>> dans le message de news: 7o4kd2F3p4qagU1@mid.individual.net...
>>> pete wrote:
>>>> Not Really Me wrote:
>>>>> 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?
>>>>
>>>> No.
>>>
>>> Thanks Pete.  Best answer of the bunch.  It is what I expected, but I
>>> needed to ask.
>>
>> Actually, there is one technical reason that has not been mentioned
>> yet... Funny it took pete's blunt answer to make me remember it:
>>
>> for(;;) is a blunt, obvious looping contruct.
>>
>> while(1) on the other hand can be confused with while(l)
>>
>> this is imho a good reason to avoid both while(1) and local variables
>> named l
>
> Putting on my Dilbert Dinosaur costume...  Back in the early 80's I was a 
> one person consulting business.  I finally hired a "receptionist/assitant". 
> She was a returning to work mother with grown kids.  The first task I gave 
> her was to type an old basic program into the computer.  You quessed?  She 
> used lower case 'l' instead of 1 throughout the program.  I was using 
> CBasic, so the code was entered in an editor, not a live basic interpreter. 
> Aargh!

Not exactly a reason to limit competent programmers however.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

Richard Heathfield <rjh@see.sig.invalid> writes:
> In <semicolon-20091209113851@ram.dialup.fu-berlin.de>, Stefan Ram 
> wrote:
>
>> Kaz Kylheku <kkylheku@gmail.com> writes:
>>>do S ;  /* semicolon required to denote infinite looping over S */
>>>Now let S be the statement ``do { } while(condition); '' and we get:
>> 
>>   The semicolon is required only in your phantasy.
>> 
>>   ISO/IEC 9899:1999 (E) reads:
>> 
>> do statement while ( expression ) ;
>> 
>>   There is no »;« after »statement«.
>
> Try telling your compiler that.

There is no ';' after 'statement'.  There may or may not be a ';' as
the last token of the statement.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On 2009-12-09, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Kaz Kylheku <kkylheku@gmail.com> writes:
>>do S ;  /* semicolon required to denote infinite looping over S */
>>Now let S be the statement ``do { } while(condition); '' and we get:
>
>   The semicolon is required only in your phantasy.

Fucking idiot, read the thread.

I feel more comfortable with:
 #define TRUE 1
do{
//...
}while(TRUE);
and I think that this is semantically more sound than the for(;;) for
me. Because when i see this snippet, in the code
the compiler in my head automatically translates it to: "do the stuffs
in the loop while all conditions are satisfied".
Also some weird staff(not sure if this is previously mentioned before)
like the following is possible which i'd recommend you to avoid from:

#include <stdio.h>
#include <stdlib.h>

int main(){
	int test_var = 0;
loop:
	test_var++;
	if( test_var == 100 ) {
		goto break_loop;
	}else {
		printf( "I'm inside the loop: %d", test_var );
	}
goto loop;

break_loop:
	printf("I'm out of loop\n");
	return EXIT_SUCCESS;
}

caglar wrote:
> I feel more comfortable with:
>  #define TRUE 1

I don't like a #define for TRUE.

> do{
> //...
> }while(TRUE);
> and I think that this is semantically more sound than the for(;;) for
> me. Because when i see this snippet, in the code
> the compiler in my head automatically translates it to: "do the stuffs
> in the loop while all conditions are satisfied".

And with no conditions, it just keeps on going. Still, different people 
think different.

> Also some weird staff(not sure if this is previously mentioned before)
> like the following is possible which i'd recommend you to avoid from:
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main(){
> 	int test_var = 0;
> loop:
> 	test_var++;
> 	if( test_var == 100 ) {
> 		goto break_loop;
> 	}else {
> 		printf( "I'm inside the loop: %d", test_var );
> 	}
> goto loop;
> 
> break_loop:
> 	printf("I'm out of loop\n");
> 	return EXIT_SUCCESS;
> }

The, I would say, is absolutely horrible. I would never pass that in a 
code review, and I don't know anyone who would.
-- 
Flash Gordon

caglar <ca9lar@gmail.com> writes:
> I feel more comfortable with:
>  #define TRUE 1
> do{
> //...
> }while(TRUE);
> and I think that this is semantically more sound than the for(;;) for
> me. Because when i see this snippet, in the code
> the compiler in my head automatically translates it to: "do the stuffs
> in the loop while all conditions are satisfied".

As I'm sure you know, it's semantically identical.

Also, putting the condition at the bottom makes it less obvious
that it's an infinite loop.  And both "while (1)" and "for (;;)"
have the considerable advantage of being common C idioms.

I rarely see or use do-while loops in C.  (I think the last time I
used one was in my IOCCC entry; I formatted the code so the "while"
looked, at first glance, like it was the top of a while loop rather
than the bottom of a do-while loop.)

> Also some weird staff(not sure if this is previously mentioned before)
> like the following is possible which i'd recommend you to avoid from:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(){
> 	int test_var = 0;
> loop:
> 	test_var++;
> 	if( test_var == 100 ) {
> 		goto break_loop;
> 	}else {
> 		printf( "I'm inside the loop: %d", test_var );
> 	}
> goto loop;
>
> break_loop:
> 	printf("I'm out of loop\n");
> 	return EXIT_SUCCESS;
> }

Yeah, and you can also use a global array as a call stack, so you
can put all your code in main() and use gotos instead of function
calls and returns.  (Each return would have to be a switch statement
so it jumps to the correct label, though you can use a simple goto
if the "function" is "called" from only one place.)  And you can
put a label on each statement:

    L10: printf("This is a loop\n");
    L20: goto L10;

And if that's not painful enough, you can glue small sharp pins to the
keys on your keyboard and soak your feet in a bucket of ice water.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On 2009-12-09, Antti-Juhani Kaijanaho <antti-juhani@kaijanaho.fi> wrote:
> On 2009-12-06, Kaz Kylheku <kkylheku@gmail.com> wrote:
>> On 2009-12-05, Antti-Juhani Kaijanaho <antti-juhani@kaijanaho.fi> wrote:
>>> 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 */
>
> Mm.  I said "after the block", not "after the statement".  But good point, I
> forgot C allows a single statement in that position.

I think that I always add braces in a do/while, even if there is just a single
expression. It's easy to see why you might forget you can have a single
statement there. 

But since we are toying with proposed syntaxes, you are right in 
that is no need for that to be the case.  This infinite looping construct based
on do could require a compount statement.

There are precedents for this in C itself and in related languages. 

In C, the body of a function must be, syntactically, a compound statement.
In principle, it could just have been any statement, allowing things like

 void foo(int x)
 switch(x)
 {
 case 42:
   break;
 }

which is actually neat. :)

In C++, a try block requires a compound statement:

  try-block ::= try compound-statement handler-seq

(but there is a function-try-block phrase which allows a try-block to be the
body of a function; which shows that someone had the mental flexibility to
uproot the idea that a function body must be a compound statement).

Keith Thompson <kst-u@mib.org> writes:

> I rarely see or use do-while loops in C.  (I think the last time I
> used one was in my IOCCC entry; I formatted the code so the "while"
> looked, at first glance, like it was the top of a while loop rather
> than the bottom of a do-while loop.)

do-while loops are certainly less common than while loops in most
C code, but I think it's absurd to imply that they're only useful
for obfuscation.

Here's one reasonable example from the source tree I'm currently
working on:

    do {
        nbytes = recvmsg(sock->fd, &msg, (wait ? 0 : MSG_DONTWAIT) | MSG_PEEK); 
    } while (nbytes < 0 && errno == EINTR);

Here's another:

    /* Tries to complete the connection on 'stream', which must be an active
     * stream.  If 'stream''s connection is complete, returns 0 if the connection
     * was successful or a positive errno value if it failed.  If the
     * connection is still in progress, returns EAGAIN. */
    int
    stream_connect(struct stream *stream)
    {
        enum stream_state last_state;

        do {
            last_state = stream->state;
            switch (stream->state) {
            case SCS_CONNECTING:
                scs_connecting(stream);
                break;

            case SCS_CONNECTED:
                return 0;

            case SCS_DISCONNECTED:
                return stream->error;

            default:
                NOT_REACHED();
            }
        } while (stream->state != last_state);

        return EAGAIN;
    }

-- 
"IMO, Perl is an excellent language to break your teeth on"
--Micah Cowan

Ben Pfaff <blp@cs.stanford.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> I rarely see or use do-while loops in C.  (I think the last time I
>> used one was in my IOCCC entry; I formatted the code so the "while"
>> looked, at first glance, like it was the top of a while loop rather
>> than the bottom of a do-while loop.)
>
> do-while loops are certainly less common than while loops in most
> C code, but I think it's absurd to imply that they're only useful
> for obfuscation.

I certainly didn't mean to imply that.  It just happens to be the last
time I used it.

[reasonable examples snipped]

I realize that, back in the Old Days when I wrote Pascal, I used
repeat-until loops more often than while loops.  It probably has
something to do with the differing ways Pascal and C do input.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Ben Pfaff <b...@cs.stanford.edu> wrote:
> Keith Thompson <ks...@mib.org> writes:
> > I rarely see or use do-while loops in C. =A0(I think the
> > last time I used one was in my IOCCC entry; I formatted
> > the code so the "while" looked, at first glance, like
> > it was the top of a while loop rather than the bottom
> > of a do-while loop.)
>
> do-while loops are certainly less common than while loops in most
> C code, but I think it's absurd to imply that they're only useful
> for obfuscation.

The syntax may be rare, but the construct is far from uncommon.

I've mentioned before that I have a header that supplies...

  #define until(expr)  while (!(expr))

I find it's usage, rare though it may be, exremely clear. Not
obfuscatory at all. The irony is that it's probably only die
hard C programmers who find it confusing!

--
Peter

Peter Nilsson wrote:
> Ben Pfaff <b...@cs.stanford.edu> wrote:
>> Keith Thompson <ks...@mib.org> writes:
>>> I rarely see or use do-while loops in C.  (I think the
>>> last time I used one was in my IOCCC entry; I formatted
>>> the code so the "while" looked, at first glance, like
>>> it was the top of a while loop rather than the bottom
>>> of a do-while loop.)
>> do-while loops are certainly less common than while loops in most
>> C code, but I think it's absurd to imply that they're only useful
>> for obfuscation.
> 
> The syntax may be rare, but the construct is far from uncommon.
> 
> I've mentioned before that I have a header that supplies...
> 
>   #define until(expr)  while (!(expr))
> 
> I find it's usage, rare though it may be, exremely clear. Not
> obfuscatory at all. The irony is that it's probably only die
> hard C programmers who find it confusing!
> 
> --
> Peter

But you see, it's not C. Seeing 'until(expr)' in a C program forces you to 
stop and look it up. It's abuse of the preprocessor in my view.

-- 
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."

Joe Wright <joewwri...@comcast.net> wrote:
> Peter Nilsson wrote:
> > Ben Pfaff <b...@cs.stanford.edu> wrote:
> > > do-while loops are certainly less common than while
> > > loops in most C code, but I think it's absurd to imply
> > > that they're only useful for obfuscation.
> >
> > The syntax may be rare, but the construct is far from
> > uncommon.
> >
> > I've mentioned before that I have a header that supplies...
> >
> > =A0 #define until(expr) =A0while (!(expr))
> >
> > I find it's usage, rare though it may be, exremely clear.
> > Not obfuscatory at all. The irony is that it's probably
> > only die hard C programmers who find it confusing!
>
> But you see, it's not C.

Macros are not C?

> Seeing 'until(expr)' in a C program forces you to
> stop and look it up.

In a dictionary perhaps, but if you find do-until confusing
you should probably pack in programming and have a go at
ballet dancing. <g>

> It's abuse of the preprocessor in my view.

NULL is an abuse of the preprocessor in mine.

--
Peter

"Joe Wright" <joewwright@comcast.net> wrote in message 
news:zNmdnSwsVKlZ2b3WnZ2dnUVZ_gGdnZ2d@giganews.com...
> Peter Nilsson wrote:
>> Ben Pfaff <b...@cs.stanford.edu> wrote:

>>> do-while loops are certainly less common than while loops in most
>>> C code, but I think it's absurd to imply that they're only useful
>>> for obfuscation.
>>
>> The syntax may be rare, but the construct is far from uncommon.
>>
>> I've mentioned before that I have a header that supplies...
>>
>>   #define until(expr)  while (!(expr))
>>
>> I find it's usage, rare though it may be, exremely clear. Not
>> obfuscatory at all. The irony is that it's probably only die
>> hard C programmers who find it confusing!

> But you see, it's not C. Seeing 'until(expr)' in a C program forces you to 
> stop and look it up. It's abuse of the preprocessor in my view.

This what I sometimes find annoying:

If a compiler already has all the gubbins needed to implement do...while, 
then it is a matter of minutes to also allow do...until. The only cost is 
one new keyword.

Clearly some people find it useful.

(Instead the trend is to remove useful bits of syntax! Many languages don't 
have goto; Python doesn't have switch (and c.l.python has questions about 
how to get around this every few days); Go doesn't have While/Do-while; and 
so on. Syntax (for control structures) has virtually zero cost, other than 
the reserved words, so I don't know what all these designers are playing 
at.)

-- 
Bartc 

On 2009-12-10, Joe Wright <joewwright@comcast.net> wrote:
> Peter Nilsson wrote:
>> Ben Pfaff <b...@cs.stanford.edu> wrote:
>>> Keith Thompson <ks...@mib.org> writes:
>>>> I rarely see or use do-while loops in C.  (I think the
>>>> last time I used one was in my IOCCC entry; I formatted
>>>> the code so the "while" looked, at first glance, like
>>>> it was the top of a while loop rather than the bottom
>>>> of a do-while loop.)
>>> do-while loops are certainly less common than while loops in most
>>> C code, but I think it's absurd to imply that they're only useful
>>> for obfuscation.
>> 
>> The syntax may be rare, but the construct is far from uncommon.
>> 
>> I've mentioned before that I have a header that supplies...
>> 
>>   #define until(expr)  while (!(expr))
>> 
>> I find it's usage, rare though it may be, exremely clear. Not
>> obfuscatory at all. The irony is that it's probably only die
>> hard C programmers who find it confusing!
>> 
>> --
>> Peter
>
> But you see, it's not C. Seeing 'until(expr)' in a C program forces you to 
> stop and look it up.

Seeing a function in a C program has the same effect.

Thus, don't use functions. Write everything as one big main.

The intelligent developer looks it up /once/.  And only to confirm that it has
exactly one definition which does what it looks like it does.

It's a one time cost. If this thing occurs multiple times in the code, the cost
may be recovered for in clarity.

You should only worry about someone having to read a definition if you are
coding for an audience of anterograde amnesiacs, who forget a definition 30
seconds after having seen it, or obsessive compulsives who think that the
definition might be changing and so have to keep looking.  Those people will
have trouble with all your functions, as well as those function- and
object-like macros that you do approve of.

Someone writing code to be read by normal people can easily justify the above
until macro.  It's either that, or negating all of the expressions, or de
Morgan's.

Sometimes, negating an expression obfuscates. Suppose that it's some
kind of invariant that is expressed in other places.

Bottom-of-loop tests often just about beg for a positive test of some kind,
whereas a negative test feels right at the top of a loop. 

  do {

  } until (invariant_satisfied(x))

or

  while (!invariant_satisfied(x))
  {
  }

Often it is the case that one or more iterations of a body ensure that
something interesting which was not true previously is now true. We confirm it
to be false at the top as the condition for executing another iteration. Or we
confirm it to be true at the bottom, and do not execute another iteration.

Keith Thompson <kst-u@mib.org> writes:

> Ben Pfaff <blp@cs.stanford.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> I rarely see or use do-while loops in C.  (I think the last time I
>>> used one was in my IOCCC entry; I formatted the code so the "while"
>>> looked, at first glance, like it was the top of a while loop rather
>>> than the bottom of a do-while loop.)
>>
>> do-while loops are certainly less common than while loops in most
>> C code, but I think it's absurd to imply that they're only useful
>> for obfuscation.
>
> I certainly didn't mean to imply that.  It just happens to be the last
> time I used it.
>
> [reasonable examples snipped]
>
> I realize that, back in the Old Days when I wrote Pascal, I used
> repeat-until loops more often than while loops.  It probably has
> something to do with the differing ways Pascal and C do input.

I've just had a look at my code base.  In 32k lines of source (excluding
header files) there are 165 hits on "while .* {" and 63 on "do {".  So
roughly a quarter of the loops are do...while - which is slightly higher
than I expected.

There are 35 "for(;;)" in there as well, often bearing comments saying
"will always exit by a return" (and one bearing the comment "barbaric
flow control!").  That also surprises me.
-- 
Online waterways route planner: http://canalplan.org.uk
           development version: http://canalplan.eu

Kaz Kylheku wrote:
[...]
> I think that I always add braces in a do/while, even if there is just a single
> expression. It's easy to see why you might forget you can have a single
> statement there. 
[...]

I, too, "usually" use braces on 1-line for/while/whatever loops.  What I can 
say I "always" do is put the body on a line apart from the control line.

I think most people here would agree that this style just "looks wrong":

     for ( foo ; bar ; baz );
or
     while ( do_something() );

That lone semicolon is too easily "lost" by the person reading the code.

The other time I "always" do something is put braces around a multi-line, 
single compound statement, body.  For example, I would not use this syntax 
which I have found in numerous places throughout code I maintain:

     for ( foo ; bar ; baz )
         if ( something )
             do_this();
         else
             do_that();

Or, worse, nested if/else without braces:

     if ( this )
         if ( that )
             do_something();
         else if ( another )
             do_another();
         else
             do_yet_another();
     else
         something_else();

Of course, due to multiple platforms with multiple editors which have 
multiple tab-stop settings, it rarely looks so nicely indented.  It can take 
several minutes "fixing" it, making sure to carefully put the braces so as 
to not change the meaning.  (Not as simple as it looks when not all "if"s 
have an "else".)

-- 
Kenneth Brody

Kenneth Brody <kenbrody@spamcop.net> writes:
>I think most people here would agree that this style just "looks wrong":
>     for ( foo ; bar ; baz );
>or
>     while ( do_something() );

  Every C programmer knows such usage from functions like
  strlen or strcpy (�while(*p++);� or �while(*p++==*q++);�)

>That lone semicolon is too easily "lost" by the person reading the code.

  If someone loses semicolons, he might not be the right
  person to review C code.

  I do not want adjust my code for people who 

      - do not know C or
      - do not see semicolons or 
      - use �gcc -Wempty-body�.

Kaz Kylheku <kkylheku@gmail.com> writes:

> I think that I always add braces in a do/while, even if there
> is just a single expression. It's easy to see why you might
> forget you can have a single statement there.

Having a closing brace on the same line as the "while" in a
do/while also avoids a potential visual ambiguity: if the
do/while's "while" is at the top of the screen in the editor
window, and there is no closing brace on that line, then it can
look like an empty "while" loop.  Scrolling up immediately makes
the situation clear, but I dislike surprises of this sort.

Coding styles that put braces and keywords on different lines
make this worse.
-- 
"C has its problems, but a language designed from scratch would have some too,
 and we know C's problems."
--Bjarne Stroustrup

Stefan Ram wrote:
> Kenneth Brody <kenbrody@spamcop.net> writes:
>> I think most people here would agree that this style just "looks wrong":
>>     for ( foo ; bar ; baz );
>> or
>>     while ( do_something() );
> 
>   Every C programmer knows such usage from functions like
>   strlen or strcpy (�while(*p++);� or �while(*p++==*q++);�)

ITYM:

     while (*p++)
         ;
and
     while (*p++ = *q++)
         ;

:-)

>> That lone semicolon is too easily "lost" by the person reading the code.
> 
>   If someone loses semicolons, he might not be the right
>   person to review C code.

Perhaps.  But, as I said, I maintain code that has been written by multiple 
coders, edited on multiple platforms with multiple editors, and with varied 
tab-stop settings;

(I was going to fix the typo on the above line, but decided to leave it as-is.)

I have come across code which looks like:

     while ( do_something(*pt++) );
         do_something_else(pt);

Is it an extraneous semicolon, or a mis-indented function call?

>   I do not want adjust my code for people who 
> 
>       - do not know C or
>       - do not see semicolons or 
>       - use �gcc -Wempty-body�.

I have no problem with "empty bodies".  It's the ambiguity (from a "human 
reading the code" standpoint) of putting the semicolon on the same line as 
the control statement.  Placing it on a line by itself makes it clear (to 
me, anyway) of the intention to have an empty body.

-- 
Kenneth Brody

Kenneth Brody <kenbrody@spamcop.net> writes:

> But, as I said, I maintain code that has been written by
> multiple coders, edited on multiple platforms with multiple
> editors, and with varied tab-stop settings;

All within a single project or source tree?  I suggest that the
problem here is really that there needs to be a single
well-defined coding style for a given project.
-- 
Ben Pfaff 
http://benpfaff.org

Kenneth Brody wrote:
> Stefan Ram wrote:
> 
>> Kenneth Brody <kenbrody@spamcop.net> writes:
>>
>>> I think most people here would agree that this style just "looks wrong":
>>>     for ( foo ; bar ; baz );
>>> or
>>>     while ( do_something() );
>>
>>
>>   Every C programmer knows such usage from functions like
>>   strlen or strcpy (�while(*p++);� or �while(*p++==*q++);�)
> 
> 
> ITYM:
> 
>     while (*p++)
>         ;
> and
>     while (*p++ = *q++)
>         ;
> 
> :-)

I still use the braces, even then.

     while (*p++) {
         ;
     }

     while (*p++ = *q++) {
         ;
     }

-- 
pete

On 12/10/2009 1:26 PM, Ben Pfaff wrote:
> Kenneth Brody<kenbrody@spamcop.net>  writes:
>
>> But, as I said, I maintain code that has been written by
>> multiple coders, edited on multiple platforms with multiple
>> editors, and with varied tab-stop settings;
>
> All within a single project or source tree?  I suggest that the
> problem here is really that there needs to be a single
> well-defined coding style for a given project.

     There was a vogue some years ago for a practice called
"egoless programming."  Had a good deal going for it, but
foundered on the scarcity of "egoless programmers" ...

     Someone who's enough of a diplomat to get a large group
of skilled programmers to agree on "a single well-defined
coding style" and to stick to that style over a period of
years and through multiple personnel changes is wasting his
talents if he uses them for mere software.  Let him instead
persuade North Korea and Iran to discontinue their nuclear
weapons programs; should be a piece of cake, comparatively.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> On 12/10/2009 1:26 PM, Ben Pfaff wrote:
>> Kenneth Brody<kenbrody@spamcop.net>  writes:
>>
>>> But, as I said, I maintain code that has been written by
>>> multiple coders, edited on multiple platforms with multiple
>>> editors, and with varied tab-stop settings;
>>
>> All within a single project or source tree?  I suggest that the
>> problem here is really that there needs to be a single
>> well-defined coding style for a given project.
>
>     Someone who's enough of a diplomat to get a large group
> of skilled programmers to agree on "a single well-defined
> coding style" and to stick to that style over a period of
> years and through multiple personnel changes is wasting his
> talents if he uses them for mere software.  Let him instead
> persuade North Korea and Iran to discontinue their nuclear
> weapons programs; should be a piece of cake, comparatively.

I don't see this problem in the projects that I work on, in my
experience.  At companies, someone decrees the coding style, and
it gets enforced via code reviews.  In the free software projects
that I work on, it's much the same.  Even on very large projects
such as the Linux kernel, the coding style is more or less
followed.
-- 
"What is appropriate for the master is not appropriate for the novice.
 You must understand the Tao before transcending structure."
--The Tao of Programming

Ben Pfaff <blp@cs.stanford.edu> writes:

> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>
>> On 12/10/2009 1:26 PM, Ben Pfaff wrote:
>>> Kenneth Brody<kenbrody@spamcop.net>  writes:
>>>
>>>> But, as I said, I maintain code that has been written by
>>>> multiple coders, edited on multiple platforms with multiple
>>>> editors, and with varied tab-stop settings;
>>>
>>> All within a single project or source tree?  I suggest that the
>>> problem here is really that there needs to be a single
>>> well-defined coding style for a given project.
>>
>>     Someone who's enough of a diplomat to get a large group
>> of skilled programmers to agree on "a single well-defined
>> coding style" and to stick to that style over a period of
>> years and through multiple personnel changes is wasting his
>> talents if he uses them for mere software.  Let him instead
>> persuade North Korea and Iran to discontinue their nuclear
>> weapons programs; should be a piece of cake, comparatively.
>
> I don't see this problem in the projects that I work on, in my
> experience.  At companies, someone decrees the coding style, and
> it gets enforced via code reviews.  In the free software projects
> that I work on, it's much the same.  Even on very large projects
> such as the Linux kernel, the coding style is more or less
> followed.

Agreed. You always get one or two whiners but if its an existing code
base they soon fall into step. The benefits are too great not too.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

On 12/10/2009 2:32 PM, Ben Pfaff wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid>  writes:
>
>> On 12/10/2009 1:26 PM, Ben Pfaff wrote:
>>> Kenneth Brody<kenbrody@spamcop.net>   writes:
>>>
>>>> But, as I said, I maintain code that has been written by
>>>> multiple coders, edited on multiple platforms with multiple
>>>> editors, and with varied tab-stop settings;
>>>
>>> All within a single project or source tree?  I suggest that the
>>> problem here is really that there needs to be a single
>>> well-defined coding style for a given project.
>>
>>      Someone who's enough of a diplomat to get a large group
>> of skilled programmers to agree on "a single well-defined
>> coding style" and to stick to that style over a period of
>> years and through multiple personnel changes is wasting his
>> talents if he uses them for mere software.  Let him instead
>> persuade North Korea and Iran to discontinue their nuclear
>> weapons programs; should be a piece of cake, comparatively.
>
> I don't see this problem in the projects that I work on, in my
> experience.  At companies, someone decrees the coding style, and
> it gets enforced via code reviews.  In the free software projects
> that I work on, it's much the same.  Even on very large projects
> such as the Linux kernel, the coding style is more or less
> followed.

     Our experiences differ, and I guess you've been more
fortunate than I in finding organizations that take niceties
like "coding style" and "code reviews" seriously.

     The largest source tree I ever worked with extensively
was about three million lines, had a history about fifteen
years long, had been worked on by maybe a hundred or hundred
fifty programmers, and was a Gawdawful mess.  But the company
had a "cowboy programmer" culture, so what would one expect?

     Another source tree I touched lightly was the product of
a highly-organized, button-down Big Company, where all the
Software Engineering Methodologies were duly observed as they
came in and out of fashion.  The source was about twenty-five
million lines, had a history stretching back some twenty-five
years, had been worked on by several hundred programmers --
and was still a Gawdawful mess despite all the methodology.

     Seems to me that "Gawdawful mess" is the norm ...

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

>     Our experiences differ, and I guess you've been more
> fortunate than I in finding organizations that take niceties
> like "coding style" and "code reviews" seriously.
[...stories...]
>     Seems to me that "Gawdawful mess" is the norm ...

I might as well relate my own experiences.  I won't bother with
the free software projects, since the source code is all out
there for everyone to look at.  I've only had two commercial
coding stints worth talking about, so I'll talk about those.

From 2003 to 2007 I worked at a very large x86 virtualization
software vendor.  Their tree was, if I recall correctly, on the
order of a million lines of code, with history stretching back to
approximately 1998.  The founder had decreed a particular (rather
odd) coding style, and the whole tree followed it with rare
exceptions.  Attempts to add code that violated it were stomped
out in code review.

In 2007 I was a founding employee at my current company.  I
decreed a coding style, and it has been followed pretty well
since then, at least in the projects in which I participate.
Again, violations are stomped out in code review.

I am probably generalizing from too few data points.
-- 
Ben Pfaff 
http://benpfaff.org

Ben Pfaff <blp@cs.stanford.edu> writes:

> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>
>>     Our experiences differ, and I guess you've been more
>> fortunate than I in finding organizations that take niceties
>> like "coding style" and "code reviews" seriously.
> [...stories...]
>>     Seems to me that "Gawdawful mess" is the norm ...
>
> I might as well relate my own experiences.  I won't bother with
> the free software projects, since the source code is all out
> there for everyone to look at.  I've only had two commercial
> coding stints worth talking about, so I'll talk about those.
>
> From 2003 to 2007 I worked at a very large x86 virtualization
> software vendor.  Their tree was, if I recall correctly, on the
> order of a million lines of code, with history stretching back to
> approximately 1998.  The founder had decreed a particular (rather
> odd) coding style, and the whole tree followed it with rare
> exceptions.  Attempts to add code that violated it were stomped
> out in code review.
>
> In 2007 I was a founding employee at my current company.  I
> decreed a coding style, and it has been followed pretty well
> since then, at least in the projects in which I participate.
> Again, violations are stomped out in code review.
>
> I am probably generalizing from too few data points.

No. You're not. I have worked on at least 10 or so large C/C++
projects. All with their own (sensible) standards : in all cases any new
hot shot that came in trying to break the standards got taken aside and
told "you might even be right, but this is the real world and in the
real world we work as a team using these standards. if you volunteer
to reformat the entire code base here and on our customer sites and run
it though a rigorous QA we MIGHT consider it. As it is there is real
work to do and we suggest you get on with it. You're not the first and
wont be the last to think your way is better. Hopefully in time you will
see there is a reason for the current standards."

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

On Dec 10, 11:38=A0pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Kenneth Brody <kenbr...@spamcop.net> writes:
> >That lone semicolon is too easily "lost" by the person reading the code.
> .
> =A0 If someone loses semicolons, he might not be the right
> =A0 person to review C code.

I don't think Kenneth was concerned to cope with *incompetent*
programmers; he just wanted to save them a few seconds' worth
of concentration by using a standard easy-to-read style.

As others point out, adding "{ ... }" even where unneeded
is often good, especially since you'll often need to add
them later anyway.  This leads to a strong argument for
a particular brace-placement style:

Using "while ... if ... else ... else ..." as example, fully
adding the "{ ... }" wastes 8 lines vertically if you always
place braces on their own line, but only 2 lines using
True Style(tm).

James Dow Allen

Keith Thompson <kst-u@mib.org> writes:
> I rarely see or use do-while loops in C.  (I think the last time I
> used one was in my IOCCC entry;

There's your mistake - you should have used recursion instead!
Then again, that doesn't always work either.

Phil
-- 
main(int O,char**l){O-1&&main((O++<0?putchar(O%
4?*1[l]++:",\n"[!O]):1[l][O-2])?O:2-4*O/3,l);}

pete <pfiland@mindspring.com> writes:
> Kenneth Brody wrote:
>> Stefan Ram wrote:
>>
>>> Kenneth Brody <kenbrody@spamcop.net> writes:
>>>
>>>> I think most people here would agree that this style just "looks wrong":
>>>>     for ( foo ; bar ; baz );
>>>> or
>>>>     while ( do_something() );
>>>
>>>
>>>   Every C programmer knows such usage from functions like
>>>   strlen or strcpy (»while(*p++);« or »while(*p++==*q++);«)
>>
>>
>> ITYM:
>>
>>     while (*p++)
>>         ;
>> and
>>     while (*p++ = *q++)
>>         ;
>>
>> :-)
>
> I still use the braces, even then.
>
>     while (*p++) {
>         ;
>     }
>
>     while (*p++ = *q++) {
>         ;
>     }

I use strlen and strcpy.

Phil
-- 
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1

On 10 Dec, 19:32, Ben Pfaff <b...@cs.stanford.edu> wrote:
> Eric Sosman <esos...@ieee-dot-org.invalid> writes:
> > On 12/10/2009 1:26 PM, Ben Pfaff wrote:
> >> Kenneth Brody<kenbr...@spamcop.net> =A0writes:

> >>> But, as I said, I maintain code that has been written by
> >>> multiple coders, edited on multiple platforms with multiple
> >>> editors, and with varied tab-stop settings;
>
> >> All within a single project or source tree? =A0I suggest that the
> >> problem here is really that there needs to be a single
> >> well-defined coding style for a given project.
>
> > =A0 =A0 Someone who's enough of a diplomat to get a large group
> > of skilled programmers to agree on "a single well-defined
> > coding style" and to stick to that style over a period of
> > years and through multiple personnel changes is wasting his
> > talents if he uses them for mere software. =A0Let him instead
> > persuade North Korea and Iran to discontinue their nuclear
> > weapons programs; should be a piece of cake, comparatively.
>
> I don't see this problem in the projects that I work on, in my
> experience. =A0At companies, someone decrees the coding style, and
> it gets enforced via code reviews. =A0

I've seen it enforced by the check-in system. You code got indented
and diffed before it was checked in. The checkin failed if diffs found
a difference. You *could* override it but then it sent an email to the
Configuration Controller...

> In the free software projects
> that I work on, it's much the same. =A0Even on very large projects
> such as the Linux kernel, the coding style is more or less
> followed.

Ben Pfaff wrote:
> Keith Thompson <kst-u@mib.org> writes:
> 
> 
>>I rarely see or use do-while loops in C.  (I think the last time I
>>used one was in my IOCCC entry; I formatted the code so the "while"
>>looked, at first glance, like it was the top of a while loop rather
>>than the bottom of a do-while loop.)
> 
> 
> do-while loops are certainly less common than while loops in most
> C code, but I think it's absurd to imply that they're only useful
> for obfuscation.

I'm fairly comfortable with do loops.

void
merg(unsigned char *base,
      unsigned char *buff,
      size_t nmemb,
      size_t size,
      int (*compar)(const void *, const void *))
{
     if (nmemb > 1) {
         void *const       after = base + nmemb * size;
         const size_t half_nmemb = nmemb / 2;
         const size_t half_bytes = half_nmemb * size;
         unsigned char *     end = half_bytes + base;
         unsigned char *    midd = end;

         merg(midd, buff, nmemb - half_nmemb, size, compar);
         merg(base, buff,         half_nmemb, size, compar);
         do {
             if (compar(base, midd) > 0) {
                 buff += half_bytes;
                 do {
                     *--buff = *--end;
                 } while (end != base);
                 end += size;
                 do {
                     *base++ = *midd++;
                 } while (base != end);
                 do {
                     if (midd != after) {
                         end += size;
                         if (compar(buff, midd) > 0) {
                             do {
                                 *base++ = *midd++;
                             } while (base != end);
                         } else {
                             do {
                                 *base++ = *buff++;
                             } while (base != end);
                         }
                     } else {
                         do {
                             *base++ = *buff++;
                         } while (base != midd);
                     }
                 } while (base != midd);
             } else {
                 base += size;
             }
         } while (base != midd);
     }
}

-- 
pete

On 12/11/2009 4:29 AM, Nick Keighley wrote:
> On 10 Dec, 19:32, Ben Pfaff<b...@cs.stanford.edu>  wrote:
>> [...]
>> I don't see this problem in the projects that I work on, in my
>> experience.  At companies, someone decrees the coding style, and
>> it gets enforced via code reviews.
>
> I've seen it enforced by the check-in system. You code got indented
> and diffed before it was checked in. The checkin failed if diffs found
> a difference. You *could* override it but then it sent an email to the
> Configuration Controller...

<topicality level="marginal">

     IMHO, that's a terrible way to do things.  By insisting on
a "canonical" arrangement of white space, it forbids the use of
white space as a medium of expression to aid readability.  Two
situations seem to crop up fairly often:

     First, when a long expression is broken across multiple lines
it can be helpful to indent the continuations so as to reflect the
logical structure of the expression.  Here's an actual example
(albeit from a "just for fun" program):

	if (SQUARE(p->crtx - ball[k].crtx)
	        + SQUARE(p->crty - ball[k].crty)
	    <= SQUARE(p->crtr + ball[k].crtr))

A style that insisted (as some do) "continuations are uniformly
indented N spaces deeper than the continued line" would, IMHO,
disimprove the readability.

     Second, it is not uncommon to display tabular information
in comments, where the horizontal position of each comment is
related not only to that of the line's "payload," but also to
the positions of comments on nearby lines.  Another example
(from another toy program, adapted from code by Paul Hsieh):

                /* If it's a straight, then ranks = ...0111110... */
unsigned int temp = ranks ^ (ranks - 1); /* temp = ...0000011... */
temp = (temp + 1) >> 1;                  /* temp = ...0000010... */
temp = (temp << 5) - temp;               /* temp = ...0111110... */

Again, a style that insisted "on-the-line comments begin in column
N (or N' spaces after the payload)" would destroy the arrangement,
depriving the reader of useful information or at the very least
making him work harder to extract it.

     We build computers to be our servants, not our masters.  When
we let an "indent" program rearrange code and disrupt the meaning
that it's too stupid to comprehend, we've surrendered to our own
tools, we have chosen not to think.

     See also "With Folded Hands" by Jack Williamson.

</topicality>

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>	if (SQUARE(p->crtx - ball[k].crtx)
>	        + SQUARE(p->crty - ball[k].crty)
>	    <= SQUARE(p->crtr + ball[k].crtr))

>A style that insisted (as some do) "continuations are uniformly
>indented N spaces deeper than the continued line" would, IMHO,
>disimprove the readability.

  I am using a uniform indentation of �2 spaces deeper�, 
  but only based on brackets, parentheses, braces and so. Thus,

if
( SQUARE( p->crtx - ball[ k ].crtx )+
  SQUARE( p->crty - ball[ k ].crty )<=
  SQUARE( p->crtr + ball[ k ].crtr ))

  This looks readable to me. My rationale:

  One Way to Format Parentheses

  There are several different ways to format texts with braces
  and parentheses. One of them is being described here.

  Indentation within Braces

  An indentation of just one space often is too small to be seen
  clearly, because the natural width and form of characters
  often varies by an amount that is not very much smaller than a
  space. Therefore, the indentation should amount to at least
  two positions. In order not to waste horizontal spaces, an
  indentation of exactly two positions is chosen. This means,
  that the left position of the next level is two larger than
  the position of the directly enclosing level.

  Indentation by two positions within a block

{ ++x;
  ++x; }
^ ^
0 2

  Bad: A small indentation by one position is not always visible
  clearly

{++x;
 ++x; }

  Good: The indentation by two positions is visible clearly

{ ++x;
  ++x; }

  Bad: A large indentation by more than two positions wastes
  horizontal space with no additional benefit

{    ++x;
     ++x; }

Spaces within braces

  In mathematics, there are often no spaces at the inner side of
  parentheses or braces in expressions, but spaces are used
  indeed at the inner side of braces in set notation, when the
  braces contain a description (not when they contain a list).

  Spaces in set notation

{ x | x  > 2 }

  This style is adopted here: One space is written at the inner
  side of braces.

  Spaces at the inner side of parentheses within a block

{ ++x; }

  This style is consistent with the indentation by two
  positions, because only using this style, corresponding parts
  of two lines have the same position.

  Bad: No space after the first brace, the two statements are
  misaligned

{++x;
  ++x; }

  Good: One space after the first brace, the two statements are
  properly aligned

{ ++x;
  ++x; }

  Bad: Two spaces after the first brace, the two statements are
  misaligned

{  ++x;
  ++x; }

  There are some exceptions to this rule: No spaces are used
  within empty braces "{}" and between two or more closing
  braces of the same direction "}}", except, when the first one
  of them is part of an empty pair "{} }" (an empty pair of
  braces if treated like a single non-braces character).

  Unified rules for all Brackets

  For simplicity and uniformity, the rules from above apply to
  all kinds of brackets, including parentheses, braces (curly
  brackets), square brackets, and angle brackets.

  Spaces within parentheses and square brackets

{ y = f( x )+ g() + a[ 2 ]; }

  Binary operators are sorrounded by a space, but the space is
  omitted, when there already is a space on the other side of a
  sequence of brackets directly beside the operator: By this rule,
  " )+" is written instead of " ) +".

  Representation of the Syntactical Structure

  A method declaration in Java consists of a head and a body.
  The following representation shows this structure:

  Good formatting according to the structure

void alpha() // head
{ beta(); }  // body

  The following formatting is misleading, because the line break
  does not match the structural break:

  Bad line break within the body

void alpha() { // head and the beginning of the body
  beta(); }    // the rest of the body

  This formatting also would make no sense for blocks within
  blocks. So it is often not used for such blocks. Therefore
  even the adopters of this style can not use it uniformly.

  Opening Braces Look Like "bullets"

  There is a well known style to publish lists in typography
  using bullets sticking out on the left, looking like this:

  Common list representation with bullets in typography

o This is the first point
  of this list, it is written
  here just as an example.

o Here is another entry

o This is another example given
  just as an example to show
  an example

  The braces of the beginnings of blocks stand out on the left
  just the same, when the formatting being described here is
  used, so they look quite naturally as beginning-of-a-block
  markers, when one is used to the typographical list notation:

  Left braces look like bullets to mark blocks

{ printf(); printf();
  printf(); printf(); printf();
  printf(); printf(); }

{ printf(); printf(); }

{ printf(); printf(); printf();
  printf(); printf();
  printf(); }

  Neutrality

  Someone wrote this C code:

while( fgets( eingabe, sizeof eingabe, stdin ))
  if( sscanf( eingabe, "%d", &wert )!= 1 )
    fprintf( stderr, "Please enter a number!\n" );
  else
    summe += wert;

  It amazes me that I can add braces by my style conventions
  (not changing the meaning of the code)
  without the need to change the position of any character of
  the given code or need to change the overall number of lines:

  The code from above plus braces

while( fgets( eingabe, sizeof eingabe, stdin ))
{ if( sscanf( eingabe, "%d", &wert )!= 1 )
  { fprintf( stderr, "Please enter a number!\n" ); }
  else
  { summe += wert; }}

  Insofar, my bracing style might be considered non-obtrusive.

  Lines per Contents

  Lines containing only a single brace waste vertical space, so
  less contents fits on the same screen space. Therefore, I usually
  avoid them, but sometimes I do use them, when this helps to
  increase readability. I also might temporarily use them when editing
  a section of code. Of course, they would help programmers paid or
  being judged by the lines-of-code productivity.

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> On 12/11/2009 4:29 AM, Nick Keighley wrote:
>> On 10 Dec, 19:32, Ben Pfaff<b...@cs.stanford.edu>  wrote:
>>> [...]
>>> I don't see this problem in the projects that I work on, in my
>>> experience.  At companies, someone decrees the coding style, and
>>> it gets enforced via code reviews.
>>
>> I've seen it enforced by the check-in system. You code got indented
>> and diffed before it was checked in. The checkin failed if diffs found
>> a difference. You *could* override it but then it sent an email to the
>> Configuration Controller...
>
> <topicality level="marginal">

Huh? What does that mean?

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>	if (SQUARE(p->crtx - ball[k].crtx)
>>	        + SQUARE(p->crty - ball[k].crty)
>>	    <= SQUARE(p->crtr + ball[k].crtr))
>
>>A style that insisted (as some do) "continuations are uniformly
>>indented N spaces deeper than the continued line" would, IMHO,
>>disimprove the readability.
>
>   I am using a uniform indentation of »2 spaces deeper«, 
>   but only based on brackets, parentheses, braces and so. Thus,
>
> if
> ( SQUARE( p->crtx - ball[ k ].crtx )+
>   SQUARE( p->crty - ball[ k ].crty )<=
>   SQUARE( p->crtr + ball[ k ].crtr ))
>
>   This looks readable to me. My rationale:
>

It is horrendous.

You really think

if(a+
   b<=
   c)

Is clear?

It is totally unreadable.

We dont use vt100s anymore.

,----
| if((SQUARE( p->crtx - ball[ k ].crtx )+ SQUARE( p->crty - ball[ k ].crty ))<= SQUARE( p->crtr + ball[ k ].crtr )){
|    f();
| }
`----

Erics is fine too

,----
| 	if (SQUARE(p->crtx - ball[k].crtx)
| 	        + SQUARE(p->crty - ball[k].crty)
| 	    <= SQUARE(p->crtr + ball[k].crtr))
`----

But I would bracket it thus

,----
| 	if ((SQUARE(p->crtx - ball[k].crtx)
| 	        + SQUARE(p->crty - ball[k].crty))
| 	    <= SQUARE(p->crtr + ball[k].crtr))
`----
There is no room for confusion

Richard wrote:
) But I would bracket it thus
)
) ,----
)| 	if ((SQUARE(p->crtx - ball[k].crtx)
)| 	        + SQUARE(p->crty - ball[k].crty))
)| 	    <= SQUARE(p->crtr + ball[k].crtr))
) `----
) There is no room for confusion

Agreed with the bracketing.  However, I'd add a bit of internal whitespace:

| 	if (    (   SQUARE(p->crtx - ball[k].crtx)
| 	          + SQUARE(p->crty - ball[k].crty))
| 	     <= SQUARE(p->crtr + ball[k].crtr))

so that it visually stands out what is grouped with what.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Willem <willem@stack.nl> writes:

> Richard wrote:
> ) But I would bracket it thus
> )
> ) ,----
> )| 	if ((SQUARE(p->crtx - ball[k].crtx)
> )| 	        + SQUARE(p->crty - ball[k].crty))
> )| 	    <= SQUARE(p->crtr + ball[k].crtr))
> ) `----
> ) There is no room for confusion
>
> Agreed with the bracketing.  However, I'd add a bit of internal whitespace:
>
> | 	if (    (   SQUARE(p->crtx - ball[k].crtx)
> | 	          + SQUARE(p->crty - ball[k].crty))
> | 	     <= SQUARE(p->crtr + ball[k].crtr))
>
> so that it visually stands out what is grouped with what.
>
> SaSW, Willem

There shouldn't be any need. Extraneous whitespace on the same line
inside part of an expression sucks most times. Brackets and a bracket
aware editor sorts that out. I find your version less readable. The
double brackets by the if and before the "<=" show you all you need to
know IMO. I would also remove the white space around "-" too btw.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

Richard wrote:
) Willem <willem@stack.nl> writes:
)
)> Richard wrote:
)> ) But I would bracket it thus
)> )
)> ) ,----
)> )| 	if ((SQUARE(p->crtx - ball[k].crtx)
)> )| 	        + SQUARE(p->crty - ball[k].crty))
)> )| 	    <= SQUARE(p->crtr + ball[k].crtr))
)> ) `----
)> ) There is no room for confusion
)>
)> Agreed with the bracketing.  However, I'd add a bit of internal whitespace:
)>
)> | 	if (    (   SQUARE(p->crtx - ball[k].crtx)
)> | 	          + SQUARE(p->crty - ball[k].crty))
)> | 	     <= SQUARE(p->crtr + ball[k].crtr))
)>
)> so that it visually stands out what is grouped with what.
)>
)> SaSW, Willem
)
) There shouldn't be any need. Extraneous whitespace on the same line
) inside part of an expression sucks most times. Brackets and a bracket
) aware editor sorts that out. I find your version less readable. The
) double brackets by the if and before the "<=" show you all you need to
) know IMO. I would also remove the white space around "-" too btw.

Why does adding whitespace make something *less* readable ?

All I can read from your arguments is that the brackets are 'good enough',
you don't seem to be mentioning one single reason why the extra whitespace
makes it *less* readable.  Nor do I see any argument refuting my point that
the elements stand out visually in this arrangement.



SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Willem <willem@stack.nl> writes:

> Richard wrote:
> ) Willem <willem@stack.nl> writes:
> )
> )> Richard wrote:
> )> ) But I would bracket it thus
> )> )
> )> ) ,----
> )> )| 	if ((SQUARE(p->crtx - ball[k].crtx)
> )> )| 	        + SQUARE(p->crty - ball[k].crty))
> )> )| 	    <= SQUARE(p->crtr + ball[k].crtr))
> )> ) `----
> )> ) There is no room for confusion
> )>
> )> Agreed with the bracketing.  However, I'd add a bit of internal whitespace:
> )>
> )> | 	if (    (   SQUARE(p->crtx - ball[k].crtx)
> )> | 	          + SQUARE(p->crty - ball[k].crty))
> )> | 	     <= SQUARE(p->crtr + ball[k].crtr))
> )>
> )> so that it visually stands out what is grouped with what.
> )>
> )> SaSW, Willem
> )
> ) There shouldn't be any need. Extraneous whitespace on the same line
> ) inside part of an expression sucks most times. Brackets and a bracket
> ) aware editor sorts that out. I find your version less readable. The
> ) double brackets by the if and before the "<=" show you all you need to
> ) know IMO. I would also remove the white space around "-" too btw.
>
> Why does adding whitespace make something *less* readable ?
>
> All I can read from your arguments is that the brackets are 'good enough',
> you don't seem to be mentioning one single reason why the extra whitespace
> makes it *less* readable.  Nor do I see any argument refuting my point that
> the elements stand out visually in this arrangement.
>
> SaSW, Willem

Because they don't. As a programmer I look for brackets and indentation, not arbitrary
white space inside expressions. I dont see how 2 spaces after the 2nd
bracket adds anything to readability. If anything it looks like someone
couldn't be bothered to clean up! 

Don't take it personally : this type of thing is a very personal issue
for all of us.

Looking at the top example above that I posted there really is not point
of confusion IMO. The "+" part is indented and the backdent of the "<="
makes it crystal clear to what is being compared.

All "IMO" of course.


-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

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

Kenneth Brody wrote:

> Kaz Kylheku wrote:
> [...]
>> I think that I always add braces in a do/while, even if there is just a
>> single expression. It's easy to see why you might forget you can have a
>> single statement there.
> [...]
> 
> I, too, "usually" use braces on 1-line for/while/whatever loops.  What I
> can say I "always" do is put the body on a line apart from the control
> line.
> 
> I think most people here would agree that this style just "looks wrong":
> 
>      for ( foo ; bar ; baz );
> or
>      while ( do_something() );
> 
> That lone semicolon is too easily "lost" by the person reading the code.
> 
> The other time I "always" do something is put braces around a multi-line,
> single compound statement, body.  For example, I would not use this syntax
> which I have found in numerous places throughout code I maintain:
> 
>      for ( foo ; bar ; baz )
>          if ( something )
>              do_this();
>          else
>              do_that();
> 
> Or, worse, nested if/else without braces:
> 
>      if ( this )
>          if ( that )
>              do_something();
>          else if ( another )
>              do_another();
>          else
>              do_yet_another();
>      else
>          something_else();
> 
> Of course, due to multiple platforms with multiple editors which have
> multiple tab-stop settings, it rarely looks so nicely indented.  It can
> take several minutes "fixing" it, making sure to carefully put the braces
> so as
> to not change the meaning.  (Not as simple as it looks when not all "if"s
> have an "else".)
> 

I always use compound statements as the bodies of control statements (if 
else for do while switch try catch).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksjr5gACgkQG6NzcAXitM8+4QCfWmOSwlcPw5L2Hlx269kHzjkq
pHsAn0UgI+bUp7Di/IbJ2lIUPXcVo/AQ
=1q7B
-----END PGP SIGNATURE-----

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

Peter Nilsson wrote:

> Joe Wright <joewwri...@comcast.net> wrote:
>> Peter Nilsson wrote:
>> > Ben Pfaff <b...@cs.stanford.edu> wrote:
>> > > do-while loops are certainly less common than while
>> > > loops in most C code, but I think it's absurd to imply
>> > > that they're only useful for obfuscation.
>> >
>> > The syntax may be rare, but the construct is far from
>> > uncommon.
>> >
>> > I've mentioned before that I have a header that supplies...
>> >
>> > #define until(expr)  while (!(expr))
>> >
>> > I find it's usage, rare though it may be, exremely clear.
>> > Not obfuscatory at all. The irony is that it's probably
>> > only die hard C programmers who find it confusing!
>>
>> But you see, it's not C.
> 
> Macros are not C?

Macros are part of C but it is completely different from C.
C is a programming language but the preprocessing language is a text 
replacement language.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksjsQcACgkQG6NzcAXitM8Z1gCdHQ3HhqI4sz8056VgSfjEI01s
jrsAoJJ0A9HlJ11gyvSpWVuL1hm0KMS3
=yWKX
-----END PGP SIGNATURE-----

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

Keith Thompson wrote:

> Michael Tsang <miklcct@gmail.com> writes:
>> Not Really Me wrote:
>>> 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.
> 
> 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.
> 

I write while(true) because I am a C++ programmer. When I need to write code 
in C, I always #include <stdbool.h> when boolean logic is needed in the 
program. Because, in C++, the condition of while is a bool so that I write 
while(true) instead of while(1) or even worse for(;;) which is completely 
nonsense for non-C programmers. (When I first seen for(;;), I think that the 
loop doesn't run at all because the condition is null.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksjsjEACgkQG6NzcAXitM8WvACeI0pZxLyvE+0nc7Tfp67JU5jZ
23MAn0pW5K4do5JOWmNxzL9nCft6B//8
=tGsi
-----END PGP SIGNATURE-----

On 12/12/2009 10:04 AM, Michael Tsang wrote:
>
> Macros are part of C but it is completely different from C.

     As you've stated it, this is nonsense.  But we think we
know what you mean, anyhow: The syntax and semantics of the
preprocessing parts of C are quite unlike those of the rest
of C.

> C is a programming language but the preprocessing language is a text
> replacement language.

     Actually, it's a token replacement language (pedantically,
a preprocessing token replacement language).  The difference
is occasionally important, as in

	#define HELLO "Bonjour"
	puts ("HELLO, WORLD!");

.... where the output is "HELLO, WORLD!" and not "Bonjour, WORLD!".

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Michael Tsang <miklcct@gmail.com> writes:
> Keith Thompson wrote:
[...]
>> 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.
>
> I write while(true) because I am a C++ programmer. When I need to
> write code in C, I always #include <stdbool.h> when boolean logic is
> needed in the program. Because, in C++, the condition of while is a
> bool so that I write while(true) instead of while(1) or even worse
> for(;;) which is completely nonsense for non-C programmers. (When I
> first seen for(;;), I think that the loop doesn't run at all because
> the condition is null.)

I find it useful to adopt the idioms of the language I'm working in.
C and C++ are two distinct (but deceptively similar) languages.

In C, the condition in a while statement is of scalar type, and
"while (1)" is a common idiom for an infinite loop.  There's nothing
wrong with "while (true)"; after all, _Bool is a scalar type as well.
(Well, there's the additional requirement for "#include <stdbool.h>",
and the risk of needing to compile your code on an implementation
that doesn't support <stdbool.h>.)

Yes, "for(;;)" is complete nonsense for non-C programmers.  So is
most of the language.  Unless you have some specific reason to want
to make your code clear to non-C programmers, don't worry about it.

At the very least, however you write your own code, you need
to understand "while (1)" and "for (;;)" when you see it in
others' code.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Michael Tsang wrote:

> I always use compound statements as the bodies of control statements 

I find that it's easier to do that always,
than it is to think about it.

-- 
pete

Michael Tsang wrote:

> Macros are part of C but it is completely different from C.

Being able to compile code which contains macros is a requirement
in order for any software to qualify as an implementation of C.

All of the rules for C macros are written in the C standard.

-- 
pete

pete <pfiland@mindspring.com> writes:
> Michael Tsang wrote:
>> Macros are part of C but it is completely different from C.
>
> Being able to compile code which contains macros is a requirement
> in order for any software to qualify as an implementation of C.
>
> All of the rules for C macros are written in the C standard.

True.

Ok, let's put it this way.  You can think of C as a combination of
two different languages.  One is the language defined by the early
translation phases, typically referred to as the preprocessor.
The other is what's produced by the preprocessor and processed by
the remaining translation phases; you can think of this language as
what C would look like if the preprocessor were dropped.  These two
languages are very different.  I think that's what Michael was
trying to say, and it's a valid point.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson wrote:
> pete <pfiland@mindspring.com> writes:
> 
>>Michael Tsang wrote:
>>
>>>Macros are part of C but it is completely different from C.
>>
>>Being able to compile code which contains macros is a requirement
>>in order for any software to qualify as an implementation of C.
>>
>>All of the rules for C macros are written in the C standard.
> 
> 
> True.
> 
> Ok, let's put it this way.  You can think of C as a combination of
> two different languages.  One is the language defined by the early
> translation phases, typically referred to as the preprocessor.
> The other is what's produced by the preprocessor and processed by
> the remaining translation phases; you can think of this language as
> what C would look like if the preprocessor were dropped.  These two
> languages are very different.  I think that's what Michael was
> trying to say, and it's a valid point.
> 

I should have tried harder to understand the value of
"Macros are part of C" as being the context
in which to interpret the meaning of
"but it is completely different from C".

-- 
pete

"Keith Thompson" <kst-u@mib.org> wrote in message
> Yes, "for(;;)" is complete nonsense for non-C programmers.  So is
> most of the language.  Unless you have some specific reason to want
> to make your code clear to non-C programmers, don't worry about it.
>
It's impossible (or at least very difficult) to write C code that doesn't 
use any C-isms.
However if people understand most of what is going on, they can often fill 
the incomprehensible bits by context. For instance when I first saw the ++ 
operator I knew that it was an increment, because I knew assembly and most 
assemblers in those days had dedicated INC instructions, also because it was 
obvious from the logic of the program that this was intended.

However if everything is incomprehensible, however, then you can't do this. 
So by systematically preferring if else to ?:, not using logical 
short-circuits, using while(true), etc, you can help people from a C-light 
background to read your code.

On 13 Dec 2009, "Malcolm McLean" <regniztar@btinternet.com> wrote:

> "Keith Thompson" <kst-u@mib.org> wrote in message
>> Yes, "for(;;)" is complete nonsense for non-C programmers.

But it's not; it works in plenty of other languages.  Admittedly, 
I'm not sure if "for(;;)" is considered as idiomatic in other 
languages as it is in C.

>> So
>> is most of the language.

But C has had a tremendous impact over the years, so some of C is 
also familiar to people who have used languages like Java, C++, 
PHP, Perl, etc.  I knew about certain C idioms before I ever read 
or wrote a line of C.  (I only started learning programming about 
six years ago.)

>> Unless you have some specific reason
>> to want to make your code clear to non-C programmers, don't
>> worry about it. 
>>
> It's impossible (or at least very difficult) to write C code
> that doesn't use any C-isms.
> However if people understand most of what is going on, they can
> often fill the incomprehensible bits by context.
[...]
> However if everything is incomprehensible, however, then you
> can't do this. So by systematically preferring if else to ?:,
> not using logical short-circuits, using while(true), etc, you
> can help people from a C-light background to read your code.

The ternary operator and short-circuit evaluation are definitely 
not particular to C only.  While I don't think you should use 
these things just because they're there, I do feel that not making 
the most of the tools you have hurts more than it helps.

Seeing as how I'm still a C newcomer, I prefer to read C that 
makes good use of C idioms; it helps me learn the language better.

-- 
"Don't worry about efficiency until you've attained correctness."
  ~ Eric Sosman, comp.lang.c

Kaz Kylheku wrote:

[snip]

> Often it is the case that one or more iterations of a body ensure that
> something interesting which was not true previously is now true. We confirm it
> to be false at the top as the condition for executing another iteration. Or we
> confirm it to be true at the bottom, and do not execute another iteration.

And sometimes we confirm it to be false at the top and confirm it again 
to be false *after* the bottom, as in this snippet of open source code 
from a file named match.c:

     while (consp(piter) && consp(viter))
     {
       bindings = dest_bind(bindings, car(piter), car(viter));
       if (bindings == t)
         return t;
       piter = cdr(piter);
       viter = cdr(viter);
     } while (consp(piter) && consp(viter));

Most if not all compilers (including those typically invoked with the 
"gcc" and "g++" commands) do not issue a warning for this code. 
Fortunately, there is at least one "compiler" that does (on the second 
while statement):

Info 722: Suspicious use of ;

The code most likely used to be a do loop that got converted to a while 
loop but was not properly "maintained". And note the inconsistency in 
the brace alignment with the rest of the code. If consistency trumps 
religious beliefs, it should be the following for the first line:

while (consp(piter) && consp(viter)) {

It should be noted that the same "compiler" issues numerous other 
warnings of potential concern on this open source code.

Regards
-- 
BB

PC-lint
http://www.gimpel.com/

Billy Bong <billyb655321@aol.com> writes:
> Kaz Kylheku wrote:
>
> [snip]
>
>> Often it is the case that one or more iterations of a body ensure that
>> something interesting which was not true previously is now true. We confirm it
>> to be false at the top as the condition for executing another iteration. Or we
>> confirm it to be true at the bottom, and do not execute another iteration.
>
> And sometimes we confirm it to be false at the top and confirm it
> again to be false *after* the bottom, as in this snippet of open
> source code from a file named match.c:
>
>     while (consp(piter) && consp(viter))
>     {
>       bindings = dest_bind(bindings, car(piter), car(viter));
>       if (bindings == t)
>         return t;
>       piter = cdr(piter);
>       viter = cdr(viter);
>     } while (consp(piter) && consp(viter));
>
> Most if not all compilers (including those typically invoked with the
> "gcc" and "g++" commands) do not issue a warning for this
> code. Fortunately, there is at least one "compiler" that does (on the
> second while statement):
>
> Info 722: Suspicious use of ;
>
> The code most likely used to be a do loop that got converted to a
> while loop but was not properly "maintained".

The first thing that went through my head was that it was someone
trying to be 'cute' by sticking the condition both at the top and 
the bottom deliberately, the latter effectively being a 'comment'.

If you're going to post an advert for something with which you're
associated, which at least is on topic I have no complaints about
that at all[*], perhaps you'd like to clearly declare an interest.

Phil
[* To be honest, the PC-lint adverts were the single best thing 
about Dr. Dobbs' Journal for the last few years when I still 
read it - I wouldn't even mind Gimpel posting regular C-related
puzzles here. Recycle those old ads! I of course don't speak for
anyone apart from myself here, obviously.]
-- 
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1

On Dec 16, 11:57=A0pm, Billy Bong <billyb655...@aol.com> wrote:
> Kaz Kylheku wrote:
>
> [snip]
>
> > Often it is the case that one or more iterations of a body ensure that
> > something interesting which was not true previously is now true. We con=
firm it
> > to be false at the top as the condition for executing another iteration=
.. Or we
> > confirm it to be true at the bottom, and do not execute another iterati=
on.
>
> And sometimes we confirm it to be false at the top and confirm it again
> to be false *after* the bottom, as in this snippet of open source code
> from a file named match.c:

Which open source project?

>
> =A0 =A0 =A0while (consp(piter) && consp(viter))
> =A0 =A0 =A0{
> =A0 =A0 =A0 =A0bindings =3D dest_bind(bindings, car(piter), car(viter));
> =A0 =A0 =A0 =A0if (bindings =3D=3D t)
> =A0 =A0 =A0 =A0 =A0return t;
> =A0 =A0 =A0 =A0piter =3D cdr(piter);
> =A0 =A0 =A0 =A0viter =3D cdr(viter);
> =A0 =A0 =A0} while (consp(piter) && consp(viter));
>
> Most if not all compilers (including those typically invoked with the
> "gcc" and "g++" commands) do not issue a warning for this code.
> Fortunately, there is at least one "compiler" that does (on the second
> while statement):

Which compiler?

On Fri, 04 Dec 2009 12:09:45 -0800, Keith Thompson <kst-u@mib.org>
wrote:

> "bartc" <bartc@freeuk.com> writes:
> [...]
> > While we're talking about aesthetics, then both for() and while() are
> > cleaner.
> >
> > There's a condition missing from the while statement, but then there's
> > also one missing from the for(;;).
> 
> If you mean literally "for()" and "while()", I hardly think that the
> aesthetics of code that won't compile is relevant.  I personally like
> 
>     loop
>         ...
>     end loop;
> 
> but that's not C either.

<OT=very much not C either>
I kinda like do...od and if...fi, and don't much mind case...esac.
But somehow loop...pool just seems to grate on my nerves.
And I don't even want to think about repeat...taeper. Ick.
</>

Squeamizh wrote:

> On Dec 16, 11:57 pm, Billy Bong <billyb655...@aol.com> wrote:
> 
>>Kaz Kylheku wrote:
>>
>>[snip]
>>
>>
>>>Often it is the case that one or more iterations of a body ensure that
>>>something interesting which was not true previously is now true. We confirm it
>>>to be false at the top as the condition for executing another iteration. Or we
>>>confirm it to be true at the bottom, and do not execute another iteration.
>>
>>And sometimes we confirm it to be false at the top and confirm it again
>>to be false *after* the bottom, as in this snippet of open source code
>>from a file named match.c:
> 
> 
> Which open source project?

The one on the left.

> 
> 
>>     while (consp(piter) && consp(viter))
>>     {
>>       bindings = dest_bind(bindings, car(piter), car(viter));
>>       if (bindings == t)
>>         return t;
>>       piter = cdr(piter);
>>       viter = cdr(viter);
>>     } while (consp(piter) && consp(viter));
>>
>>Most if not all compilers (including those typically invoked with the
>>"gcc" and "g++" commands) do not issue a warning for this code.
>>Fortunately, there is at least one "compiler" that does (on the second
>>while statement):
> 
> 
> Which compiler?

The one on the right.

On 2009-12-17, Billy Bong <billyb655321@aol.com> wrote:
> Kaz Kylheku wrote:
>
> [snip]
>
>> Often it is the case that one or more iterations of a body ensure that
>> something interesting which was not true previously is now true. We confirm it
>> to be false at the top as the condition for executing another iteration. Or we
>> confirm it to be true at the bottom, and do not execute another iteration.
>
> And sometimes we confirm it to be false at the top and confirm it again 
> to be false *after* the bottom, as in this snippet of open source code 
> from a file named match.c:
>
>      while (consp(piter) && consp(viter))
>      {
>        bindings = dest_bind(bindings, car(piter), car(viter));
>        if (bindings == t)
>          return t;
>        piter = cdr(piter);
>        viter = cdr(viter);
>      } while (consp(piter) && consp(viter));

Thanks for that, Billy.

Not an actual bug though.

> It should be noted that the same "compiler" issues numerous other 
> warnings of potential concern on this open source code.

The open source code has a bug database and mailing list; reports and
patches are welcome.

Joe Wright <joewwright@comcast.net> wrote:

> Certainly not C. It is xBASE (dBASE, FoxBASE, FoxPro, Clipper, et. al.) and 
> is used in FOR/NEXT and DO WHILE/ENDDO constructs. LOOP is equivalent to 
> continue; and EXIT equivalent to break;.
> 
> I prefer C but am paid to do xBASE.

Tu quoque, fratre?

Richard

Richard Bos wrote:
> Joe Wright <joewwright@comcast.net> wrote:
> 
>> Certainly not C. It is xBASE (dBASE, FoxBASE, FoxPro, Clipper, et. al.) and 
>> is used in FOR/NEXT and DO WHILE/ENDDO constructs. LOOP is equivalent to 
>> continue; and EXIT equivalent to break;.
>>
>> I prefer C but am paid to do xBASE.
> 
> Tu quoque, fratre?
> 
> Richard

Ja, Ich Auch.

-- 
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."

Joe Wright <joewwright@comcast.net> wrote:

> Richard Bos wrote:
> > Joe Wright <joewwright@comcast.net> wrote:
> > 
> >> Certainly not C. It is xBASE (dBASE, FoxBASE, FoxPro, Clipper, et. al.) and 
> >> is used in FOR/NEXT and DO WHILE/ENDDO constructs. LOOP is equivalent to 
> >> continue; and EXIT equivalent to break;.
> >>
> >> I prefer C but am paid to do xBASE.
> > 
> > Tu quoque, fratre?
> 
> Ja, Ich Auch.

Isn't it remarkable how "enjoying" the "amenities" of an "advanced",
"user-friendly" language like xBase makes you appreciate the advantages
of a primitive, boorish one like C?

Richard

Richard Bos wrote:
> Joe Wright <joewwright@comcast.net> wrote:
> 
>> Richard Bos wrote:
>>> Joe Wright <joewwright@comcast.net> wrote:
>>>
>>>> Certainly not C. It is xBASE (dBASE, FoxBASE, FoxPro, Clipper, et. al.) and 
>>>> is used in FOR/NEXT and DO WHILE/ENDDO constructs. LOOP is equivalent to 
>>>> continue; and EXIT equivalent to break;.
>>>>
>>>> I prefer C but am paid to do xBASE.
>>> Tu quoque, fratre?
>> Ja, Ich Auch.
> 
> Isn't it remarkable how "enjoying" the "amenities" of an "advanced",
> "user-friendly" language like xBase makes you appreciate the advantages
> of a primitive, boorish one like C?
> 
> Richard

I was having speed issues appending text files to DBF tables with FoxPro 
and with Clipper. I decided to try it in C. The primitive and boorish 
version was 4 times faster than Clipper and 8 times faster than FoxPro.

The C program was compiled with DJGPP and so suffers whatever overhead 
ntvdm.exe imposes. I should recompile it for native Windows and see if it 
speeds up even more.

-- 
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."