Self-modifying code
Guy Harris
guy at gorodish.Sun.COM
Tue Jul 26 04:17:11 AEST 1988
> 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.
More information about the Comp.lang.c
mailing list