« PreviousContinue »
The second program is self-checking and tests
FOR, one in each section. As with other tests of control statements, the diagnostics are rather sparse for failures. Check Volume 2 for an example of correct output.
Exceptions In Subscripts And Arguments
The exceptions specified in section 7 and 8 apply to numeric expressions in whatever context they occur. These tests simply assure that the correct values are supplied, e.g.,
machine infinity for overflow, zero for underflow, and that the execution continues normally as if that value had been put in that context as, say, a numeric constant. Sometimes this action will produce normal results and sometimes will trigger another exception, e.8.,
machine infinity supplied as a subscript. Simply verify that the exception reports are produced
in the individual tests.
Exceptions In Other contexts: PRINT, IF, ON-GOTO, FOR
As in the immediately preceding section, these tests make sure that the recovery procedures have the natural effect given the context in which they occur. As usual for exception
tests, it is up to you to verify that reasonable exception reports appear. The PRINT tests also require user interpretation to some degree.
This group consists mostly of error tests in which the error is tied not to some specific functional area but rather to the general format rules for BASIC programs. If you are not already thoroughly familiar with the general criteria for error tests, it would be wise to review them (sections 3.2.2 and 18.104.22.168 of this document) before going through this group. A few tests require special comment and this is supplied below in the
Many implementations of BASIC allow programs to omit the keyword LET in assignment statements. This program checks that possibility and reports the resulting behavior if accepted.
Sections 3 and 4 of the ANSI standard specify several context sensitive rules for the occurrence of spaces in a BASIC program. The standard test assures that wherever one space may occur,
several spaces may occur with no effect, except within a quoted- or un quoted-string. There are
certain places where spaces either must,
may, or may not appear, and the error programs test how the implementation treats various violations of the rules.
These programs test the effect of using either a single
or double quote in a quoted string. Some processors may interpret the double quote as a single occurrence of the quote character within the string. The programs test the effect of aberrant quotes in the context of the PRINT and the LET statements.
The first of these programs is a standard, not an error, test. It verifies that leading zeros in line numbers have no effect. The other programs all deal with some violation of the syntax rules for line numbers. When submitting these programs to your implementation, you should not explicitly call for any sorting or renumbering of lines. If the implementation sorts the lines by default, even when the program is submitted to it in the simplest way, the documentation must make this clear. Such sorting merely constitutes a particular type of syntactic enhancement,
to treat a program with lines out of order as if they were in order. Similarly, an implementation may discard duplicate lines, or append line numbers to the beginning of lines missing them, as long as these actions occur without special user intervention and are documented. Of course, processors may also reject such programs, with an error message to the user.
This program tests the implementation's reaction to a line whose length is greater than the standard limit of 72. Many implementations accept longer lines; if so the documentation must specify the limit.
Margin Overflow For Output Line
This is not an error test, but a standard one. Further, it involves PRINT capabilities and therefore calls for careful user interpretation. Its purpose is to assure correct handling of the margin and print zones, relative to the implementation-defined length for each of those two entities. After
entered the appropriate values, the
program will generate pairs of output, with either one or two printed lines for each member of the pair. The first member is produced
primitive capabilities of PRINT and is intended to show what the output should look
like. The second member of the pair is produced using the facilities under test and shows what the output actually looks like. If the two members differ at all, the test fails. It could happen, however, that the first member of the pair does not produce the correct output either. You should, therefore, closely examine the sample output for this test in Volume 2 to understand what the expected output is. of course the sample is exactly correct only for implementations with the same margin
and zone width, but allowing for the possibly different widths of your processor, the sample should give you the idea of what your processor must do.
These two tests tell you whether your processor
handle lowercase characters in the program, and, if so, whether they are converted to uppercase or left as lowercase.
This program tests whether your
implementation accepts comparison operators other than the standard = or <> for strings. If the processor does accept them, the program assumes that the interpretation is the intuitively appealing one and prints informative output concerning the implicit character collating sequence and also some comparison results for multi-character strings.
Mismatch of Types In Assignment
These programs check whether the processor accepts assignment of a string to a numeric variable and vice-versa, and if so what the resulting value of the receiving variable is. As usual, make sure your documentation covers these cases if the implementation accepts these programs.
TABLES OF SUMMARY INFORMATION ABOUT THE TEST PROGRAMS
This section contains three tables which should help you find
your way around the programs and the ANSI standard. The first table presents the functional grouping of the tests and shows which programs are in each group and the sections of the ANSI standard whose specifications are being tested thereby. The second table lists all the programs individually by number and title, and also the particular sections and subsections of the standard to which they apply. The third table lists the sections and subsections of the standard in order, followed by a list of program numbers for those sections. This third table is especially important if you want to test the implementation of only certain parts of the standard. Be aware, however, that since the sections of the standard are not tested in order, the tests for a given section may rely on the implementation of later sections in the standard which have been tested earlier in the test sequence.