An area for improvement is error detection in JBasic’s statement compiler methods. Previously, the above syntax just resulted in the last FILE clause parsed being used as the value of the file name.
This could easily result in unintended consequences in the user’s program, obviously. However, the parsing code in the statement compilers for these kinds of clauses tends to be a while() loop that looks for valid clauses and stores away the values. The compilers need to be upgraded to remember which clauses have been seen and to reject statements with invalid or ambiguous repeated clauses.
The OPEN statement is the first of these that I’m cleaning up, but there will be a few more. And in general, the current development version (2.5) should feature more robust syntax error detection and reporting across the language.
The error reporting will also be updated; currently too many errors (such as most syntax errors in the OPEN statement) are reported as a FILESYNTAX error, but the subsitution parameter describes the detailed error - “multiple FILE names given” - and that is a constant in the compiler method. These will be extracted as separate message codes, and the substitution parameter will be the more detailed message code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An area for improvement is error detection in JBasic’s statement compiler methods. Previously, the above syntax just resulted in the last FILE clause parsed being used as the value of the file name.
This could easily result in unintended consequences in the user’s program, obviously. However, the parsing code in the statement compilers for these kinds of clauses tends to be a while() loop that looks for valid clauses and stores away the values. The compilers need to be upgraded to remember which clauses have been seen and to reject statements with invalid or ambiguous repeated clauses.
The OPEN statement is the first of these that I’m cleaning up, but there will be a few more. And in general, the current development version (2.5) should feature more robust syntax error detection and reporting across the language.
The error reporting will also be updated; currently too many errors (such as most syntax errors in the OPEN statement) are reported as a FILESYNTAX error, but the subsitution parameter describes the detailed error - “multiple FILE names given” - and that is a constant in the compiler method. These will be extracted as separate message codes, and the substitution parameter will be the more detailed message code.