W
Wojtek Lerch
Douglas A. Gwyn said:(Perhaps more importantly, pointers also have types.)
They do, but that's simple. The type can be easily tracked down at compile
time.
Those are restrictions, not a difference in the fundamental meaning.
They draw the line between defined behaviour and undefined behaviour.
That's a pretty fundamental thing in a language standard. When the standard
neglects to tell us where that line is, I'd consider that to be a pretty
fundamental defect.
Again, the model is of storage locations, and there are restrictions
(motivated by a desire for faster execution on some architectures).
No, the model is of arrays and their elements. That's how the standard
describes additive operators and equality operators when their operands are
pointers, and a lot of other operations are defined by reference to addition
and equality. The standard seems to assume that for every pointer that
points to an object, the object either is an element of one particular
array, or is not an array element at all. The restrictions are based on
that array. The problem is that for most non-trivial conversions that
produce a pointer value, the standard neglects to mention whether that value
points to an array element or what array that element belongs to; at best,
we're just told where the object it points to is located. When you try to
add an integer to such a pointer, the standard clearly says that the range
of integers that can be added to it is restricted, but fails to explain what
the restriction is.
There aren't all that many allowed operations for pointers.
There are a lot of differently defined conversions that produce pointers.
Very few of them bother to explain the restriction on the integers that can
be added to the resulting pointer. Nevertheless, the description of the
addition operator makes it clear that there always is a restriction. For
any pointer value, there are some integer values that invoke undefined
behaviour when added to the pointer; but when the pointer is the result of a
conversion, in most cases all the standard tells us about those integer
values is that zero is not one of them.
In some cases it's obvious what the standard really intended to promise us.
For instance, it says that converting a pointer to intptr_t and back
produces a pointer that compares equal to the original. But "everybody
knows" that the standard means to guarantee more than just that -- the
result not only compares equal to the original, but also points to an
element (or past the end) of the same array as the original. In other
words, has the same restrictions on the range of integers that can be added
to it. But the text never actually says that, because that part of the
standard happens to only care about the address ("location") that the
pointer points to, and forgets about the other information (the
"restrictions") that the standard associates with pointer values.
Assigning to the same type presumably loses no information.
The range of integers for which addition has defined behaviour is not the
kind of information that can be preserved or lost by an assignment or
conversion or other operations; it's the kind of information that the
standard should tell us, because without it, the line between defined
behaviour and undefined behaviour is missing. Imagine that the standard
neglected to define the type of certain expressions -- would you also say
that those expressions "lose" the information about the type, or would you
simply say that there's a defect in the standard that needs to be fixed?