Xref: utzoo comp.lang.c:11551 comp.arch:5772
Newsgroups: comp.lang.c,comp.arch
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Self-modifying code
Message-ID: <1988Jul29.200655.27896@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> <1988Jul23.221743.22169@utzoo.uucp> <477@m3.mfci.UUCP>
Date: Fri, 29 Jul 88 20:06:55 GMT

In article <477@m3.mfci.UUCP> colwell@mfci.UUCP (Robert Colwell) writes:
>... there is
>an awful lot the compiler can't know about -- programs that use input
>data, generate pointers, or do just about anything else that's
>interesting, are going to do many operations that are difficult for
>the compiler to validate at compile time.

My personal thesis is that the difficulty of doing this in a well-written
program -- I am not interested in poorly-written ones -- is consistently
overestimated.  Remember, the programmer is supposed to be sure that these
errors aren't going to happen, because even if they are caught immediately
they are generally a disaster for production code.  Frequently, the sort
of checks that a programmer must put in to be sure about such things are
the sort of thing that a compiler ought to be able to spot fairly easily,
e.g. validation of input data.

>I'm not sure I catch your drift on the imposition of runtime checks.
>To me, the best human debuggers have the ability to figure out the
>fastest which assumptions are being made that are wrong, thus getting
>to the heart of some problem the quickest.  If I have a program bug,
>I want the machine to express as directly as possible the intent of
>my program so that I can narrow the bug-space down to my code alone.

We may have a slight misunderstanding here, which I admit I didn't notice
in my original posting.  I'm not claiming that run-time checks aren't
useful during debugging.  However, I claim that run-time checks are not
a particularly good approach to catching problems during production use,
because "subscript error in line 32, core dumped" can be every bit as
bad as trash output in a production environment.  What one really wants
is a *guarantee* that (in the absence of hardware malfunction), it will
not happen.  This cannot be achieved by testing, regardless of how much
help the hardware provides.

>I sure hope you're right.  In fact, if progress towards this goal
>becomes evident, I'd propose we start discussing ways of turning
>architecture towards better ways of supporting this instead of
>throughput or programming environments.

This is actually a programming-environment issue, though, and architecture
is nearly irrelevant.  A much more important issue is the programming
languages being used, and how tractable they are.  C, for example, is not
a very favorable case -- too many problems with pointers.
-- 
MSDOS is not dead, it just     |     Henry Spencer at U of Toronto Zoology
smells that way.               | uunet!mnetor!utzoo!henry henry@zoo.toronto.edu