Self-modifying code

[Henry Spencer]

In article <477 at m3.mfci.UUCP> colwell at 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 at zoo.toronto.edu