Xref: utzoo comp.lang.c:11509 comp.arch:5710
Path: utzoo!attcan!uunet!yale!mfci!colwell
From: colwell@mfci.UUCP (Robert Colwell)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Self-modifying code
Message-ID: <479@m3.mfci.UUCP>
Date: 26 Jul 88 12:41:23 GMT
References: <5262@june.cs.washington.edu> <260@thor.wright.EDU>
Sender: root@mfci.UUCP
Reply-To: colwell@mfci.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 56

In article <61251@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes:
>In the case of programs that use input data, said programs should validate the
>input data before using it (unless they have good reason to know the data will
>*never* be incorrect); I would prefer to see
>
>	input, line 12: value "12038" is out of range (should be between
>	  17 and 137)
>
>than to see
>
>	ILLEGAL ARRAY REFERENCE: "frobozz.q", line 31
>		Subscript was 12038; should be between 17 and 137
>
>Yes, but does this need "architectural" support, at least in the sense of
>"instruction set architecture"?  If a compiler for a "conventional" machine can
>do that level of validation, subscript-range checking features in the
>instruction set would be seldom, if ever, used.
>
>If "architecture" includes the compiler, then I agree that "architectural"
>support for this would be nice.

But the whole point of capability machines (to name a single example)
is that one cannot cover the space of all interesting
exception-possibilities using only a compiler, no matter how smart.
For one thing, the program could be coercing data types back and
forth such that checking an operation on a type can only be done at
the time the operation is applied.

But a more fundamental matter is how one manages the development of a
large software project with dozens of programmers contributing to a
single large end product.  The modules are all separately compiled,
so there is no question of the compiler helping out much.

Given access to all the symbol tables, you could imagine the linker
doing some reasonable checks of consistency (number and types of
args, for instance), but even that fails when pointers are being
passed (pointers to functions, even).

You can catch a lot of the common cases with good programming style,
as you note above.  But you can't catch them all, and the question
that capability machines pose is "how close can we come to an
airtight programming environment, and how much would it cost"?
(simplistic paraphrase, I know; maybe it'll draw some capability
people out of their woodwork abstraction!)

And how about functional languages?  Again, the compiler can only do
so much, and the space it covers is not intuitively obvious to the
programmer.  If it doesn't entirely cover the bug-space, and you
aren't sure what it *does* cover, then the coverage is much less
useful (and may not be useful at all, as Henry Spencer was alluding
to in an earlier post.)

Bob Colwell            mfci!colwell@uunet.uucp
Multiflow Computer
175 N. Main St.
Branford, CT 06405     203-488-6090