Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!brolga!bunyip.cc.uq.oz.au!uqvax.cc.uq.oz.au!wattle!cszthomas
From: rnews@qut.edu.au
Newsgroups: comp.object
Subject: Re: Type-safe does not mean safe
Message-ID: <18260.27130e32@qut.edu.au>
Date: 10 Oct 90 12:04:02 GMT
References: <3832@osc.COM> <1990Oct2.170910.4805@eua.ericsson.se>  
 <CLINE.90Oct4111329@cheetah.ece.clarkson.edu> <1990Oct5.010703.16019@Neon.Stanford.EDU> <1990Oct5.184609.7942@odi.com>
Organization: Queensland University of Technology
Lines: 48

In article <1990Oct5.184609.7942@odi.com>, dlw@odi.com (Dan Weinreb) writes:
> In nearly every implementation of Pascal, Fortran, C, and C++ that I
> know about, if you make an array of 7 elements and store a value into
> the 10th element of the array, execution of the program will happily
> complete the operation, almost certainly clobbering random unrelated
> variables and/or objects, creating a bug that is relatively hard to
> find.  (I know that there are exceptional implementations, such as
> Sabre C; this lack of checking is not a property of the language per
> se, but of most implementations of the language.)

Actually this operation is illegal in ISO Pascal and most (at least
all that I have used) implementations of Pascal will catch this error
at run-time (as will most strongly typed languages that I know of).
Only if you explicitly tell the compiler not to check for such range
errors will you get the problem you state (granted in Turbo Pascal v3
this is the default, but I think that they are the only ones to set
such an idiotic default.)

 ... comment that Lisp and Smalltalk will catch said problem at 
     run-time deleted ...

> The same goes for languages with dynamic memory allocation and
> freeing, such as C, C++, and PL/I (and probably some Pascal dialects):
> in nearly every implementation, it is possible for a program to free
> memory while there are still outstanding pointers to that memory, and
> then use the pointers without any detection of error, leading to
> incorrect results or errors signalled way down the road, making the
> bug hard to find.  This doesn't happen in Lisp and Smalltalk, which
> use automatic memory deallocation.

Good point, and a strong argument for the need for efficient and safe
GC's for all languages that are used for Programming in the Large.

I agree with your comments that these problems that you have stated
are very important and should be handled by any language that is used
for programming in the large.  I also agree with you that strict typing
rules are also very useful for large scale programming as well (though
not as useful as the above two restraints).  Programming large scale
projects without both of these facilites invariably leads to needless
frustrations and bugs (as mine and everyone I know experiences has
shown.)

Au revoir,

@~~Richard Thomas  aka. The AppleByter  --  The Misplaced Canadian~~~~~~~~~~~@
{ InterNet: R_Thomas@qut.edu.au           ACSNet:  richard@earth.qitcs.oz.au }
{ PSI:      PSI%505272223015::R_Thomas                                       }
@~~~~~School of Computing Science - Queensland University of Technology~~~~~~@