2 Dec
2010
2 Dec
'10
10:19 p.m.
On 12/2/2010 2:59 PM, Ethan Dicks wrote:
On Thu, Dec 2, 2010 at 3:32 PM, Richard<legalize at
xmission.com> wrote:
While we are at it, please don't optimize out while (1) { } as a forever
(or semi-forever if there is the possibility of a break) either. :-)
BTW, I realize I'm another curmudgeon at large, but I claim the intent
of while (1) is more immediately obvious than for (;;). I also claim
the difference matters. FWIW, I also claim that many other matters of
style matter as well, and that they in fact matter a great deal if one
takes more than an immediate view of one's code. I suppose I also would
claim that one should always take a relatively long term view of one's
code. The trick of course is determining just how long the long term
is, so the appropriate amount of effort is applied to make the code
maintainable without making the project take forever.
Later,
Charlie C.
In article<AANLkTi=9NwjfxZvaz2H-btkzt8q-c9ErbpNYW+hMfMe=(a)mail.gmail.com>om>,
Ethan Dicks<ethan.dicks at gmail.com> writes:
It is valid. C does not require that all (or in fact any) portion of
the for() construct be populated, so with no condition clause, the
loop will never exit without a break; The following line is a valid
statement in C for "no operation", a lexical placeholder. It should
evaluate the same as "{ }". The whole effect is to say "forever, do
nothing". Running on a machine with a modern operating system, your
process should loop endlessly until killed. On an embedded processor
(the context I mentioned at the start), there's no "process" as such,
so nothing to be killed, and with no programmatic escape from the
loop, all you can do is restart the processor.
I've used it as a "hang forever" debugging token to let me step
through bits of embedded code and go no further - that way, I can
reset the machine, watch various things happen, I/O lines change
state, etc., then know that below a certain point in the code,
activity beyond fetching the same address endlessly will cease.
I wouldn't want my C compiler to optimize out the null-statement since
it "does nothing". It does nothing forever, but it does it
intentionally.
-ethan
I have used the following in embedded code to
tight-loop the CPU in
certain circumstances, intentionally requiring a reset of the
processor to escape...
for (;;)
;
I don't see how this is an infinite loop requiring reset of the
processor to escape since the condition clause is empty.
In fact,
since the condition clause is empty, I'm not even sure its
syntactically valid, but C is strange enough that it may be
syntactically valid but not intuititve.