Xref: utzoo comp.lang.c:11467 comp.arch:5640
Newsgroups: comp.lang.c,comp.arch
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Self-modifying code
Message-ID: <1988Jul23.221743.22169@utzoo.uucp>
Organization: U of Toronto Zoology
References: <5262@june.cs.washington.edu> <260@thor.wright.EDU> <759@cernvax.UUCP> <472@m3.mfci.UUCP> <60782@sun.uucp> <473@m3.mfci.UUCP>
Date: Sat, 23 Jul 88 22:17:43 GMT

In article <473@m3.mfci.UUCP> colwell@mfci.UUCP (Robert Colwell) writes:
>... The capability people argue that the same
>thing extends into all areas of computer systems.  Recall the classic
>arguments about turning off runtime bounds checking to reclaim that
>lost performance -- why should a programmer, in the best of all
>possible worlds, have to worry about things like that?  ...

My counterargument is that it is almost as much of an imposition on the
programmer to have such checks done at runtime as it is to have them not
done at all.  Given the impossibility of complete testing, there is no
way to guarantee such tests will catch a bug during development.  This
means that the programmer has to go through the same complicated exercise
of trying to assure himself that the problem will never happen.  What is
really wanted is a way to check these properties at COMPILE TIME... in
which case the runtime checks become largely superfluous anyway.

Can it be done?  Well, in one sense the answer is clearly yes, because a
proof of program correctness has to include it, and we know that automating
such proofs is possible (although seldom practical at the moment).  The
question is whether it can be done with practical, affordable machinery
without crippling the language.  My own long-held conjecture is that the
answer is "yes", but I don't have proof of that yet.
-- 
Anyone who buys Wisconsin cheese is|  Henry Spencer at U of Toronto Zoology
a traitor to mankind.  --Pournelle |uunet!mnetor!utzoo! henry @zoo.toronto.edu