by my references, I read that the below (x = n if no break) is true. However should that not be the case, and Keil can change it there is a great risk, thus I'd like another read on it.
a for loop
for ( x = 0 ; x < n ; x++) { ....... if (cond) break; ....... } if (x = n) { // there was no break
can I count on x = n if 'cond' was never met and no break happened?
If that is not something that Keil can change, but standard, I can save a bunch of flags
Erik
The above is a very common test, and allowed.
Note that you have managed to do an assign in your last if test.
No, Keil can not break this. The code optimizer may switch order of things, but (with exception of timing) must guarantee the logic sqeuence of the program.
x != n if and only if the loop did break early.
I think instead of if (x = n) you mean if (x == n).
Jon
I DO know that cut-and-paste is the way to go, this, however, was a fasttyped illustration, I would NEVER have any variables as meaningless as x and n. Yes, I am thankful to Keil that they spit out a warning for if (x = n).
" I am thankful to Keil that they spit out a warning for if (x = n)"
If 'n' is a constant, you can help to protect against this by writing the comparison the other way around; ie,
if( N == x )
because the typo would then give you something entirely invlaid:
if( N = x )
After 20(?) years 'programming' in 'C':
for ( x = 0 ; x < n ; x++) { ....... if (cond) break; ....... }
That's quite remarkable.
I took a quick look at the C99 spec, and it doesn't seem to explicitly say. The ISO C99 spec is probably a suspect source anyway, since Keil doesn't even claim C99 compatibility in the first place, and also because C99 introduces the ability to declare loop variables in the loop, a la C++.
Flying off at a tangent: Now that I've made the mistake of actually looking at the spec, I've acquired extra confusion. Referring to declarations in a for loop, it says:
If clause-1 is a declaration, the scope of any variables it declares is the remainder of the declaration and the entire loop, including the other two expressions; it is reached in the order of execution before the first evaluation of the controlling expression.
The scope of such loop control variables changed back and forth in C++ before it was standardized. Originally such variables didn't exist outside the scope of the loop. But then, as a practical matter, it's often useful to know the termination value outside the loop, as in Eric's question, and so the C++ committee moved the scope of the declaration to the enclosing block, so that the loop control variable would continue to exist after the loop. Otherwise you have to declare an extra variable just to record the termination value. But this text seems to say that C99 kept the original definition, and the variable exists only in the scope of the loop.
The ISO C99 spec is probably a suspect source anyway, since Keil doesn't even claim C99 compatibility in the first place
Quite certainly true for Erik's Keil compiler, i.e. C51. The ARM tools might very well support C99.
and also because C99 introduces the ability to declare loop variables in the loop, a la C++
Precisely. As far as standard C before C99 was concerned, Erik's original observation is correct, but C99's support for loop-scoped variables muddies that water.
Otherwise you have to declare an extra variable just to record the termination value
Not really. You just have to move the definition to a place before the for loop. Immediately before should do:
int i = 0; for ( ; i < 20 ; i++) { /* some code */ }
Oh: and before I forget, let me remark that this situation:
about C my references are a bit unclear re this
by my references, I read that the below (x = n if no break)
urgently calls for some trashing of "C references" that aren't worthy of the space they occupy on the shelf.
Both references I have DO state something about this; however not in the form "at exit .... They both describe "evaluation sequence" neither states that the increment is mandatory if the loop will exit anyhow.
Both references I have DO state something about this; however not in the form "at exit ....
That is because:
They both describe "evaluation sequence" neither states that the increment is mandatory if the loop will exit anyhow.
The evaluation sequence, plus knowledge of what the operators '=', '<' and '++' do give you all the information you need to determine the value of your variable 'x' at exit of the loop.
The book can't possibly anticipate every question that might arise from the reader's reluctance, or inability, to understand the information it does provide.