Xref: utzoo comp.lang.misc:1465 comp.lang.pascal:821
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!umd5!uvaarpa!virginia!scl
From: scl@virginia.acc.virginia.edu (ACC)
Newsgroups: comp.lang.misc,comp.lang.pascal
Subject: Re: Threatening Pascal Loops
Message-ID: <793@virginia.acc.virginia.edu>
Date: 19 Apr 88 21:32:28 GMT
References: <2827@enea.se> <1557@pasteur.Berkeley.Edu> <2773@mmintl.UUCP> <294@tmsoft.UUCP> <11047@shemp.CS.UCLA.EDU> <3364@omepd> <11369@shemp.CS.UCLA.EDU>
Reply-To: scl@virginia.acc.Virginia.EDU (Steve Losen)
Organization: University of Va., Charlottesville, VA
Lines: 58

In article <11369@shemp.CS.UCLA.EDU> gast@lanai.UUCP (David Gast) writes:
>In article <3364@omepd> bobdi@omepd.UUCP (Bob Dietrich) writes:
>>In article <11047@shemp.CS.UCLA.EDU> gast@lanai.UUCP (David Gast) writes:
>
...
>The following program is also illegal, but again, I suspect that
>most compilers do not detect the error.  The standard Berkeley 4.3
>compiler does not.
>
>	program ILLEGAL (output);
>	var
>		i : integer;
>	procedure p ;
>		begin
>			writeln(i);   /* Variable I is undefined at this point */
>		end;
>	
>	begin
>		for i := 1 to 10 do
>			writeln(i); 
>		p;
>	end.
>
>Essentially, slightly over stated, one will have to guarantee that
>a loop control variable is never used outside the scope of the for
>loop or do extensive run-time checking.
>

Unless the standard changes, Pascal compilers have no choice but to do
extensive run-time checking.

Nothing in the Pascal standard forbids you from using the index variable
any way you wish outside the for loop and within the block enclosing the
loop.  The above example would be perfectly legal if "i" were assigned
a legal value just after the loop and before the call to "p".
The real problem here is detecting the use of undefined variables. 
In addition to the for index becoming undefined at the end of
a for loop, local variables are undefined upon activation of their
enclosing procedure or function.  The variables returned by new() are
undefined.  After a call to put(), such as put(f), the buffer variable
f^ is undefined.  And so on.

It would be very nice if there were more hardware support for runtime
checking.  Imagine the compiler assigning to an undefined variable
a magic cookie that would cause a hardware exception if that variable was
ever read.  As a matter of fact such a beast exists on some CDC cyber
systems.  The cyber uses 1's complement arithmetic.  As such, there are
two representations for zero -- positive zero (all bits clear) and
negative zero (all bits set).  Negative zero can't be used in calculations.
The cyber has (had?) a FORTRAN compiler with an option to initialize all
data space to -0.  Then any attempt to use an uninitialized variable would
halt the program.  

Of course the classic tradeoff here is speed vs. security.  If more of
the dirty work could be shoved into hardware (as has been done with
virtual memory) then fast and secure compilers would be easier to build.
-- 
Steve Losen     scl@virginia.edu
University of Virginia Academic Computing Center