Serious FOR bug in latest dev build s1964

[boriel]

Sorry for the delay in answering this (a very busy week!). This problem is very well known and discussed in other posts, and it's related to the loop boundary. The problem is wat einar pointed above: the loop uses 8 bits and it overflows. The problem is the compiler, usually, cannot guess it in compile time. Consider this:

Code:

DIM a AS UBYTE
RANDOMIZE
LET a = INT(RND * 256)
FOR i = 0 TO RND * 2:
   [...]
END

The compiler cannot guess the value of a in compile time, so it won't be able to know if the buffer overflows or not.
If it does, it should emit a warning or convert a to Uinteger. If it not, then it should leave it as it is.
The difference both in memory and performance is enough to leave it as it is, this is problem everybody (Me included!) bumps into when starting using a compiler. It's equivalent to C: for (i = 0; i < 256; i++) being i of byte type.

I was curious enough to hack a fix myself though it probably needs to be thought threw a bit more by someone more familiar with the compiler such as yourself. Anyway here it is:

If zxbparser.py line 1351:

Code:

id_type = common_type(common_type(p[4], p[6]), p[7])

is changed to these two lines:

Code:

beyond = make_number(p[6].value + p[7].value,p.lineno(2)) # upperbound + step
id_type = common_type(common_type(p[4], beyond), p[7])

that seems to fix the problem

Not sure (will study it this evening), but I guess the code I put above will make your fix to fail, because value is only for constants expressions.
For the record:

• 3 + 25 * (32 / 3) is a constant expression
  
• 2 * a or RND * 4 is not.

Having said that, it's true that for constant expressions (like your first example) the compiler may warn you of the problem.
Also, another trick is to convert your for to a DO LOOP, which allows you to use 8 byte integers:

Code:

LET n = 1
DO
[...]
LOOP UNTIL n = 255