Daniel Keep wrote:
> You're missing the point. It's not the moment at which the dereference
> happens that's the problem. As you point out, we have a hardware trap
> for that.
>
> It's when a null *gets assigned* to a variable that isn't ever supposed
> to *be* null that's the problem. That's when the "asserts up the
> posterior" issue comes in, because it's the only mechanism we have for
> defending against this.
I like this formulation of the problem, because it points to related
issues. E.g., out-of-bounds checks. In this code:
char[5] arr;
int idx;
…
idx = 7;
arr[idx] = "d";
the actual bug is in the expression “idx = 7”, although it’s only the
indexing in the next line that triggers diagnostics.
To avoid this class of bug, you need a simple way to declare what the
acceptable values for a variable are. For a pointer, it ought never to
be null, or to point outside the address space, or…
Can contracts be applied to individual objects, or only to types?
—Joel Salomon
