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

[Phil Carmody]

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

 

[Squeamizh]

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?

     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?

 

[David Thompson]

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

 

[Billy Bong]

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.

Which compiler?

The one on the right.

 

[Kaz Kylheku]

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.

 

[Richard Bos]

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]

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