🚀 go-pugleaf

Subject: Re: SUN pascal
Newsgroups: net.lang.pascal
Summary: no errors
References: <557@bu-cs.UUCP>

In article <557@bu-cs.UUCP>, budd@bu-cs.UUCP (Philip Budne) writes:
> 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.
> -----
> 
> 
> 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

concerning program q, the iso definition does not require that
any check be made here.  if your complaint is that "the definition
should require a check" then ok, but if your complaint is that
"implementation x is faulty because it doesn't check" then you have
no case.  As an aside, i point out that the kind of a check that is
appropriate here is NOT a "range check".  Range checks are only to insure that
the value of any variable or subscript is in the range or subrange specified
by the variable or subscript type.  There is a problem with program q,
but it is not a range problem.

concerning program z, again there is no error.  the function "chr" is
responsible for checking that it's argument has a value between 0 and 127.
since, in program z, it was called with the value 10, all is ok.  i think
your confusion arises because you think that it is somehow the compiler's 
job to prevent the possibility of chr ever receiving a phony value,
when in fact the compiler is only responsible for the type checking
of such function calls and functions are responsible for run-time range checks.
Note that there is no "type" error in program z since the type -128..127
is compatible with "integer", which is what chr requires.  Also,
since your complaint is based on the fact that i is typed -128..127,
you should also complain if i were simply typed "integer" since integer is
just shorthand for -??..?? in any given implementation.  but you wouldn't
complain if i were integer, now would you?