Re: Out-of-bounds nonsense
Frederick Gotham wrote:
Over on comp.lang.c, we've been discussing the accessing of array elements
via subscript indices which may appear to be out of range. In particular,
accesses similar to the following:
int arr[2][2];
arr[0][3] = 7;
Undefined behavior. In both C and C++. Since at least C90
(which as far as I know, introduced the concept).
Both the C Standard and the C++ Standard necessitate that the four int's be
lain out in memory in ascending order with no padding in between, i.e.:
(best viewed with a monowidth font)
--------------------------------
| Memory Address | Object |
--------------------------------
| 0 | arr[0][0] |
| 1 | arr[0][1] |
| 2 | arr[1][0] |
| 3 | arr[1][1] |
--------------------------------
And how is the memory layout relevant?
One can see plainly that there should be no problem with the little snippet
above because arr[0][3] should be the same as arr[1][1],
No. Since arr[0][3] doesn't exist in a legal program, it
doesn't refer to anything. With at least one compiler I've
heard of, it would cause an assertion failure.
but I've had
people over on comp.lang.c telling me that the behaviour of the snippet is
undefined because of an "out of bounds" array access. They've even backed
this up with a quote from the C Standard:
J.2 Undefined behavior:
The behavior is undefined in the following circumstances:
[...]
- An array subscript is out of range, even if an object is apparently
accessible with the given subscript (as in the lvalue expression
a[1][7] given the declaration int a[4][5]) (6.5.6).
Are the same claims of undefined behaviour existing in C++ made by anyone?
They're part of the standard. At no time was it even considered
that C style arrays would work differently in C++.
If it is claimed that the snippet's behaviour is undefined because the
second subscript index is out of range of the dimension,
It's not "claimed". It's the standard. The reason there is an
explicit example in C99 is because people tried to reason like
you in C90. The C committee has explicitly ruled that this
reasoning is falicious. Given an explicit ruling by the
committee, I'd say that the question is closed.
then this
rationale can be brought into doubt by the following breakdown. First let's
look at the expression statement:
arr[0][3] = 9;
The compiler, both in C and in C++, must interpret this as:
*( *(arr+0) + 3 ) = 9;
In the inner-most set of parentheses, "arr" decays to a pointer to its
first element, i.e. an R-value of the type int(*)[2]. The value 0 is then
added to this address, which has no effect. The address is then
dereferenced, yielding an L-value of the type int[2]. This expression then
decays to a pointer to its first element, yielding an R-value of the type
int*. The value 3 is then added to this address.
Which is undefined behavior. You cannot add three to a pointer
to the first element of an int[2].
(In terms of bytes, it's p
+= 3 * sizeof(int)). This address is then dereferenced, yielding an L-value
of the type int. The L-value int is then assigned to.
The only thing that sounds a little dodgy in the above paragraph is that an
L-value of the type int[2] is used as a stepping stone to access an element
whose index is greater than 1 -- but this shouldn't be a problem, because
the L-value decays to a simple R-value int pointer prior to the accessing
of the int object, so any dimension info should be lost by then.
Who says dimension information will be lost? The wording of the
C standard was carefully crafted intentionally to allow
implementations in which pointers carried bounds information.
At least one compiler (Centerline) used this technique in a
debugging implementation.
To the C++ programmers: Is the snippet viewed as invoking undefined
behaviour? If so, why?
It's clearly undefined behavior. If by why, you mean why the
standard says it's undefined behavior, the reason is clear:
compatibility with C. And the reason why C says it is undefined
behavior is precisely to allow checking implementations.
To the C programmers: How can you rationalise the assertion that it
actually does invoke undefined behaviour?
The standards committee has said so, explicitly. If the
standard says that X is undefined behavior, it is undefined
behavior. If you don't think it should be, write up a proposal
to change it, but until the committee has accepted your
proposal, there's not much room for argument here.
I'd like to remind both camps that, in other places, we're free to use our
memory however we please (given that it's suitably aligned, of course).
Such as? The C++ standard (and to a lesser degree the C
standard), is fairly strict in what it allows.
For
instance, look at the following. The code is an absolute dog's dinner, but
it should work perfectly on all implementations:
/* Assume the inclusion of all necessary headers */
void Output(int); /* Defined elsewhere */
int main(void)
{
assert( sizeof(double) > sizeof(int) );
{ /* Start */
double *p;
int *q;
char unsigned const *pover;
char unsigned const *ptr;
p = malloc(5 * sizeof*p);
q = (int*)p++;
pover = (char unsigned*)(p+4);
ptr = (char unsigned*)p;
p[3] = 2423.234;
*q++ = -9;
Undefined behavior. About the only thing you can legally do
with a q, here, is cast it back to a double*, and even that
isn't guaranteed to work (since in theory at least, an int*
could be smaller than a double*, and information could have been
lost).
do Output(*ptr++);
while (pover != ptr);
Note that this is only legal insofar as ptr is an unsigned char*
(or a char*, in C++). There is a special exception to the
typing rules that allows you to access any type as if it were an
array of unsigned char (or char in C++). Thus, for example, in
your initial example of int[2][2], you can iterate through the
array with:
for ( unsigned char* p = arr; p != arr + sizeof( arr ) ; ++ p ) {
// ...
}
But this special exception only concerns unsigned char (and char
in C++).
return 0;
} /* End */
}
Another thing I would remind both camps of, is that we can access any
memory as if it were simply an array of unsigned char's. That means we can
access an "int[2][2]" as if it were simply an object of the type "char
unsigned[sizeof(int[2][2])]".
Yes. That is a special exception.
The reason I'm writing this is that, at the moment, it sounds like absolute
nonsense to me that the original snippet's behaviour is undefined, and so I
challenge those who support its alleged undefinedness.
Whether you consider it nonsense or not, the C committee has
explicitly ruled on the issue. I don't know what further
support you need than an explicit statement in the standard that
is it undefined.
I leave you with this:
int arr[2][2];
void *const pv = &arr;
int *const pi = (int*)pv; /* Cast used for C++ programmers! */
pi[3] = 8;
Undefined behavior. In C++, this is a static_cast; the only
thing you can legally do with a void* in C++ is cast it back to
the original type (except, of course, copying and assigning it).
In this code, the original type is int (*)[2], and you convert
it back to int*. This is no more legal than if you cast a
double* to void*, then to int*, and expected it to work.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]