Out of range pointers

[Doug Gwyn]

In article <33432 at cca.CCA.COM> g-rh at XAIT.Xerox.COM (Richard Harter) writes:
>In C a pointer is a fairly anonymous object.  What you are saying is
>that it is a potential error to add or subtract an integer from a
>pointer if the result is out of range.  Very well, but what is that
>range?

Wherever the actual data is, plus a nonexistent extra member just past
the end of an array.  But you knew that.

>Suppose a pointer is passed through a calling sequence.  In
>the function I have no way of knowing whether &x[n] will break for any
>n other than 0.  For that matter I have no way of knowing whether 
>x is a legal pointer!

That's not quite the same issue.  One presumes that your functions have
interface specifications, which if adhered to guarantee proper operation.
The code defining the function must of course implement those
specifications.  The C language does not provide the means to completely
specify all relevant aspects of an interface in the C code itself, nor
does it require run-time enforcement of the interface specifications.
It does permit some degree of compile-time checking of the interface.

>In principle this is not right -- there is no way to write defensive
>code to check on pointer validity.  To be sure a "correct" program
>never has an invalid pointer and all that but what about the rest of
>us poor mortals?

I suppose you should all learn ways to produce correct code.  Many
such methods were figured out in the 1970s and should be part of
every professional programmer's repertoire by now.

If you ever get the chance to help design a brand-new programming
language, you might consider building in stronger aids for interface
specification checking.  Ada tried that but didn't carry it far enough.