Dear experts,

with my recent contributions I gave two good reasons for correcting 
FB with respect to the FOR-condition:

1. The FB behavior does neither follow the original BASIC conventions 
nor that of the current ANSI/ISO-BASIC standards.

2. The FB behavior is logically wrong.

That said, the header of this thread should read: "Corrected FOR behavior".


The first time I became aware of this strange FB-behavior was when I 
had to translate a quite complicated and highly optimized algorithm 
from PASCAL to FB. To demonstrate that my translation was perfectly 
correct, turned out to be very difficult. It took me days to realize 
that it wasn't although the "literal" translation seemed to be ok. 
There was little chance for debugging because it had required deep 
research and studying of the algorithm and especially of its 
optimization...
Well, I might have overlooked something and so I started an 
independent translation from FORTRAN to FB. Of course with the same 
outcome. It was only by chance that I've finally--ten days 
later--discovered the reason for the discrepancy: execution of a 
FOR-loop although its condition wasn't met.

I can't remember whether I've written a bug report to Staz or whether 
I was merely happy to have gained an astounding insight and of course 
a solution to the problem.


The statement that this FB "behavior ... has worked just fine for 
many years" obviously doesn't apply to this case and I should like to 
say that in this respect FB was "truly broken".

Concerning the FOR-issue there is one minor excuse:
The FB reference manual states in the FOR-loop entry:
"Notice that the statements in statementBlock are always executed at 
least once."

More could be said about "not perfectly logical" behavior that in 
binary logic reduces to false behavior but I shall stop for now.

Best to all
-- 

                   Herbie

          ------------------------
          <http://www.gluender.de>