budd@bu-cs.UUCP (Philip Budne) (05/06/86)
Transposrting some pascal code from a BSD4.2 system to a SUN3.0 system I ran into some range check problems. The first would appear to be an actual error (in the ISO defintion), and the other a SUN pascal bug. ----- program q(input,output); var a : 0 .. 100; i : integer; begin i := 0; for a := 0 to i-1 do writeln(output, a); end. ----- program z; var c : char; i : -128 .. 127; begin i := 10; c := chr( i ); end. ----- For more entertainment I tried the same programs under TOPS-20/Rutgers and VMS v4 pascal: q z TOPS err ok SUN err err BSD ok ok VMS ok ok The range violation in Z clearly a SUN bug, but Q would appear to be implementation dependant, it all depends on when you perform the range check (and if you check the loop limits before you start). Phil Budne / Boston University / Distributed Systems
hedrick@topaz.RUTGERS.EDU (Charles Hedrick) (05/06/86)
a : 0 .. 100; i := 0; for a := 0 to i-1 The standard says that the lower and upper bounds must be assignment compatible with the control variable if the statement is executed. In this case, the loop is from 0 to -1, so the loop is not executed. Thus the compatibility test is not to be enforced. This code is therefor legal. i : -128 .. 127; i := 10; c := chr (i); The standard says that the argument to chr must be compatible with integer, which it is. The actual value passed must translate to a legal character, or it is an error. It is up to the implementation as to what characters are legal. At first glance, I would say that 10 is a legal character. The only excuse I can think of is that 10 is really a linefeed. One might take the view that linefeed is not a legal character in a Unix implementation of Pascal, since it can never be read. Read will treat it as an end of line marker and turn it into a blank. I suggest trying the same program with a value of i that is some printable character. Incidentally, your table showed that TOPS-20 Pascal rejects the first example. That was a bug, and was fixed on 29-Jan-84.