David Brown <david.brown@hesbynett.no> writes:The compiler can only assume that if it knows that the controlling expression - the call to "something_really_bad_happened()" - does not contain any IO operations, volatile accesses or atomic operations.
[...]The idea of all this is given in a footnote in the C standards - "ThisHow about a loop that has a non-constant condition, but that is
is intended to allow compiler transformations such as removal of empty
loops even when termination cannot be proven."
>
The loop might originally have contained source code, but become empty
through pre-processing, or from other compiler transformations (such
as the compiler seeing that the "keep_going" variable is not volatile
and its value is never used, so assignments to it can be elided, or
moving other things outside the loop body).
>
A programmer /could/ write the "keep_going" loop you gave, and
mistakenly believe it to be infinite. But is it likely? In my
experience, infinite loops are generally very clearly written - either
as "for (;;)" loops or "while (true)" loops - or they are the result
of bugs in the code that accidentally run forever. If the loop is
accidentally infinite, the programmer will already be expecting it to
run the code after the loop.
not expected to terminate in normal usage?
while (! something_really_bad_happened()) {
sleep(1);
}
self_destruct();
A compiler could "assume" that the loop terminates, even if
something_really_bad never happens, and that assumption could result in
a call to self_destruct(). There are probably better ways to do that,
but it's straightforward code with seemingly obvious semantics that
an implementation is permitted to make unwarrated assumptions about.
Les messages affichés proviennent d'usenet.