Rachel Schwab at NIH has kindly run A.H.J. Sale's Pascal Validation Suite for me. There are 4 kinds of tests: conformance - see if a correct program works deviance - see if an incorrect program is detected error check - see if runtime checks work quality - see how well the compiler handles things where the implementor has the option of being cheap I am starting on conformance tests, as these seem the most crucial. The summary states that of 137 tests, there were 21 failures. I am going to list the failures. Some of these should just be taken as warnings that until I fix them, the things shown will not work. In other cases I am looking for advice. 6.2.2-3 Arthur Sales' favorite bug: type T=foo; procedure x; type X=^T; T=bar X ends up defined as ^foo when it should be ^bar. this is because the compiler is a bit too much one-pass. This is fixable, and I will fix it. Note that the problem is the fact that T was defined at an outer block level. Had the T=foo not been there, x=^T would have been recognized as a forward reference and handled properly. FIXED 6.2.2-8 Assignment to a function works only at the top level of the function. It should also work within any functions declared within that function. I guess I agree with that. This should be easy to fix, if everyone agrees with Sales' interpretation of the language spec. FIXED 6.4.3.3-1 and 6.4.3.3-3 Compiler ill mem ref's when compiling some degenerate record declaration. Probably a null record declaration. This should be easy to fix. FIXED 6.4.3.5-1 Supposedly the compiler failed when asked to compile file of a pointer type. I claim that the test is erroneous. First, it is not clear to me what a file of pointers is. But more important, they have FILE OF X, where X is a local variable. I have tried a simple test using FILE OF ^INTEGER, and it seems to work (though I am still not sure what it means). ERROR IN TEST 6.4.3.5-2 This is the first of several tests that fail because of the way EOLN is handled. In the Revised Report, when you reach the end of line on INPUT, INPUT^ is supposed to contain a blank, and GET(INPUT) will get the first char of the next line. In this implementation, INPUT^ contains , , or whatever. And if the end of line is ,, it takes two GET's to get to the next line. However a single READLN will still work. Other tests that fail because of my current end of line processing will simply refer to "the EOLN problem". FIXED 6.5.1-1 Arrays of files are not allowed nor are files allowed to be items in a record. FIXED. 6.6.3.1-5 and 6.6.3.4-2 These two tests purport to test what goes on when you pass procedures as parameters to other procedures. Unfortunately they assume a non-standard syntax for procedure declarations in this case (the syntax in the ISO proposal rather than in the Revised Report). As far as I know, our system would handle their test properly if the syntax was fixed. Eventually I will probably adopt the ISO syntax also. TEST BASED ON ISO 6.6.5.2-3 This program does RESET(FYLE), where FYLE is a local variable (i.e. not mentioned in the program statement), and no REWRITE has ever been done to the file. My Pascal distinguishes between empty files and files that do not exist at all. This test wants the file to be treated as empty, i.e. the RESET works but you get EOF(FYLE). Instead my runtime system complains that you have tried to open a non-existent file "DSK:FYLE.", and prompts for a new file name (at least I hope that is what it did - Rachel didn't say exactly what happened). Clearly my intepretation is a remnant of thinking of FILE's in Pascal as operating system files, rather than as abstract sequence variables. For my purposes my interpretation is more useful. However I agree with Sales that the language seems to imply the other interpretation. I seem to have the following choices: - another {$... kludge - another optional extra parameter to RESET - ignore the Pascal spec I regard the abstract sequence interpretation as a nightmare and propose to ignore this problem. FIXED for internal files. For external files it seems most likely that this is a user error, and you are still prompted for a new file name. 6.6.2-3 Some undetermined error with EXP, apparently a bad value returned. Unless my real number scanner is doing something bad, this seems to imply a precision problem of some sort in the underlying routine. Since EXP calls the Fortran library function, this would be DEC's problem. they are redoing the whole Fortran library because of precision problems, so I will tentatively say this is being taken care of. (But I will check to make sure it is really Fortran's fault.) UNKNOWN, probably not a problem 6.8.3.5-4 Compiler does not handle a sparse CASE statement. I believe this has been fixed since. FIXED FIXED 6.9.4-3, 6.9.4-4, 6.9.4-7, and 6.9.5-1 These tests check what is written by WRITE applied to integers, reals, Booleans, and WRITELN. To check exactly what is written, they read the string back into a packed array of char, and then look at it. Alas, since standard Pascal can't read into strings, they use code like for i := 1 to 10 do read(b[i]); Now the problem with this is the B is a packed array. According to the Revised Report, it is illegal to pass an element of a packed array to a procedure by reference. It seems that this is exactly what is being done, and the compiler refuses it. The problem, of course, is that call by reference is done by passing an address, and there is no address to pass for an object in the middle of a packed array. (They could have passed a byte pointer, but then procedures taking reference parameters would have to assume that all of its parameters are byte pointers, which would slow things down.) Now we could certainly change the implementation such that READ is not implemented by passing the address of B[I]. Instead the internal routines could be made into functions, and the compiler could retrieve the returned value and assign it. The compiler could then do the deposit byte into packed structures. But I guess I think that what they have done is in fact illegal Pascal, and I don't know how much trouble I want to go to to make it work. FIXED (i.e. you can now read into packed objects) Rachel tells me that some of these tests still don't work. I have checked Jensen and Wirth, and think that WRITE does what it says. I conjecture that these tests are TEST BASED ON ISO [or Sales interpretation] 6.9.4-15 I will have to look into this. Rachel seems to have mistyped something. But what it looks like is that if you do WRITE(X), where X is not a file (i.e. you default the output file name), you get the current definition of OUTPUT. That is, if you have a local variable called OUTPUT, that is what you get. According to the Revised Report, when you default the file name you get the standard file OUTPUT, not whatever local definition may be in effect. This should be easy to fix, and I will fix it. FIXED Other problems not showing up in the validation suite: READ and WRITE are not implemented for non-TEXT files. READ(f,x) should be equivalent to x := f^; get(f) in this case. FIXED The funny pseudo-type POINTER cannot be passed by reference. The code clearly does not intended to distinguish between call by ref and call by value for these pseudo-types. There is a history of sufficient subtlety that I don't dare change this right before a major release of the system. FIXED Upper and lower case letters are treated as the same in sets COMPLEX - will not be fixed soon Only 5 parameters can be passed to a parametric procedure. The problem here is the with Jensen and Wirth's parametric procedures, one can't verify at compile time that the number of parameters the user has passed is right. One could do it at runtime, but special machinery would be needed. If the user gets it wrong, the stack will be blown, and nobody (probably even PASDDT) will know what is going on. I decided to be safe by only allowing the number of args that will fit into the AC's. Then if he blows it, nothing serious will be wrong. This whole problem will go away when the ISO standard is adopted and I implement it, since one will be able to check arguments at compile time. COMPLEX - will not be fixed soon It is not possible to read the smallest negative integer. This will never show up on a validation test, since I can read -MAXINT. COMPLEX - requires rewriting integer read, which will not be done soon