Compiler bug fix ***SERIOUS*** (edit 747): referencing a variable in a MAP statement initializer was causing the side-effect of finalizing the parent MAP1 definition, which was then causing it be encoded in the RUN file with the wrong size. For example:
MAP1 VARX
MAP2 VAR1,F
MAP2 VAR2,S,10,SOMEOTHERVAR
MAP2 VAR3,S,16
In the above example, the reference to SOMEOTHERVAR was causing the compiler to finalize the VARX definition, which was effectively give it a size of 6 rather than 32. Symptoms included incorrect result of the LEN(VARX) function, truncated file reads/writes—if VARX was used as a file record, and truncated memory transfers if VARX was used in an assignment or passed to a function or subroutine. The problem would also occur if another type of statement—e.g. PRINT or an assignment, which referenced a variable, was inserted in the middle of a series of MAP2+ statements. But note that it only affected the case where the source expression included a variable; it did not affect literals. So in the above example, if SOMEOTHERVAR was replaced with "THIS STRING", it wouldn't have been a problem.
These are all pretty serious side effects, and would not likely escape notice, although it would have been—and was!—very hard to debug the underlying cause. However, since the problem was introduced in compiler edit 609 (A-Shell 6.1.1316.0, August 2012), it is probably the case that anyone running on 6.1 for very long didn't use the problem initialization technique. But it remains a concern for anyone upgrading from 6.0 or prior, who are thereby strongly encouraged to upgrade to at least this version.
