Xref: utzoo comp.lang.c:11498 comp.arch:5695
Path: utzoo!attcan!uunet!husc6!think!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Self-modifying code
Message-ID: <61251@sun.uucp>
Date: 25 Jul 88 18:17:11 GMT
References: <5262@june.cs.washington.edu> <260@thor.wright.EDU> <759@cernvax.UUCP> <477@m3.mfci.UUCP>
Sender: news@sun.uucp
Lines: 52

> We probably agree that the compiler should check as much as it
> possibly can; the earlier an error is detected, the less the
> ambiguity about what is wrong and the cheaper the cure.  But 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.

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

as the former, at least, tells me that the ultimate problem is in the data, not
the code.  Could a compiler know to remove run-time subscript checks in:

	i = read();
	if (i < 17 || i > 137)
		fail("input, line %d: value "%d" is out of range (should be
		    between 17 and 137");
	printf("input value for %d is %d\n", i, array[i]);

If so, it should probably issue warnings when it *isn't* able to remove
run-time subscript checks, to inform programmers that they should probably
put those checks in themselves.

> >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.
> 
> 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.

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.