Array indexing

[Joshua Neuheisel]

The following code compiles with gcc 3.2.2 and Visual C++ 6:

#include <stdio.h>
int main()
{
int a[2] = {3, 4};
printf ("%d\n", 0[a]);
return 0;
}

The unusual part is the "0[a]". The compilers translate this to
"a[0]" with no warning. Has anyone else seen this behavior, or better
yet, can anyone explain it? It seems like "index[array]" is
equivalent to "array[index]".

[Joona I Palaste]

Joshua Neuheisel <jn********@msn .com> scribbled the following:

The following code compiles with gcc 3.2.2 and Visual C++ 6: #include <stdio.h>
int main()
{
int a[2] = {3, 4};
printf ("%d\n", 0[a]);
return 0;
} The unusual part is the "0[a]". The compilers translate this to
"a[0]" with no warning. Has anyone else seen this behavior, or better
yet, can anyone explain it? It seems like "index[array]" is
equivalent to "array[index]".

Yes, it certainly is. What's more, any expression such as "a[b]" is
equivalent to "b[a]" if exactly one of a, b is a pointer and the other
is a scalar integer.
This is a deliberate feature of C, and is completely standard, portable,
and safe. It's due to the fact that a[b] gets internally translated to
*(a+b), and + is commutative.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Remember: There are only three kinds of people - those who can count and those
who can't."
- Vampyra

[Tom St Denis]

Joshua Neuheisel wrote:

The following code compiles with gcc 3.2.2 and Visual C++ 6:

#include <stdio.h>
int main()
{
int a[2] = {3, 4};
printf ("%d\n", 0[a]);
return 0;
}

The unusual part is the "0[a]". The compilers translate this to
"a[0]" with no warning. Has anyone else seen this behavior, or better
yet, can anyone explain it? It seems like "index[array]" is
equivalent to "array[index]".

That actually makes sense.

Say &a[0] is 0x30000000

Then (int)a == 0x30000000 is valid.

Then 0[a] simply means *(&0 + a) which is *(0 + 0x30000000) == *(0x30000000)

Assuming that is what happened. And no, index[array] != array[index]
since index[array] will not multiply index by the sizeof array[0].

Tom

[Tom St Denis]

Tom St Denis wrote:

Assuming that is what happened. And no, index[array] != array[index]
since index[array] will not multiply index by the sizeof array[0].

Oops, it does.

Oh well.

Tom

[Ben Pfaff]

jn********@msn. com (Joshua Neuheisel) writes:

The unusual part is the "0[a]". The compilers translate this to
"a[0]" with no warning.

This is in the FAQ.

6.11: I came across some "joke" code containing the "expression "
5["abcdef"] . How can this be legal C?

A: Yes, Virginia, array subscripting is commutative in C. This
curious fact follows from the pointer definition of array
subscripting, namely that a[e] is identical to *((a)+(e)), for
*any* two expressions a and e, as long as one of them is a
pointer expression and one is integral. This unsuspected
commutativity is often mentioned in C texts as if it were
something to be proud of, but it finds no useful application
outside of the Obfuscated C Contest (see question 20.36).

References: Rationale Sec. 3.3.2.1; H&S Sec. 5.4.1 p. 124,
Sec. 7.4.1 pp. 186-7.

--
"When in doubt, treat ``feature'' as a pejorative.
(Think of a hundred-bladed Swiss army knife.)"
--Kernighan and Plauger, _Software Tools_

[Christian Bau]

In article
<Ni************ ********@news02 .bloor.is.net.c able.rogers.com >,
Tom St Denis <to********@iah u.ca> wrote:

Joshua Neuheisel wrote:

The following code compiles with gcc 3.2.2 and Visual C++ 6:

#include <stdio.h>
int main()
{
int a[2] = {3, 4};
printf ("%d\n", 0[a]);
return 0;
}

The unusual part is the "0[a]". The compilers translate this to
"a[0]" with no warning. Has anyone else seen this behavior, or better
yet, can anyone explain it? It seems like "index[array]" is
equivalent to "array[index]".

That actually makes sense.

Say &a[0] is 0x30000000

Then (int)a == 0x30000000 is valid.

Then 0[a] simply means *(&0 + a) which is *(0 + 0x30000000) == *(0x30000000)

Assuming that is what happened. And no, index[array] != array[index]
since index[array] will not multiply index by the sizeof array[0].

Tom, will you please get your copy of the C Standard out, read the
definition of the [] operator, think about it, and then post a
correction?

[Keith Thompson]

Ben Pfaff <bl*@cs.stanfor d.edu> writes:
[...]

6.11: I came across some "joke" code containing the "expression "
5["abcdef"] . How can this be legal C?

A: Yes, Virginia, array subscripting is commutative in C. This
curious fact follows from the pointer definition of array
subscripting, namely that a[e] is identical to *((a)+(e)), for
*any* two expressions a and e, as long as one of them is a
pointer expression and one is integral. This unsuspected
commutativity is often mentioned in C texts as if it were
something to be proud of, but it finds no useful application
outside of the Obfuscated C Contest (see question 20.36).

References: Rationale Sec. 3.3.2.1; H&S Sec. 5.4.1 p. 124,
Sec. 7.4.1 pp. 186-7.

Array subscripting is commutative because addition is commutative.

In most uses of the addition operator, the left and right operands are
of the same type. The exception to this is pointer arithmetic; you
can't sensibly add two pointers, but you can add a pointer and an
integer, yielding a pointer as the result. Both "pointer + integer"
and "integer + pointer" are legal and have the same meaning.

In my opinion, it would have been no loss to the language if the
pointer were required to be the left operand. Certainly there would
be no loss of expressive power. As a side effect of such a change,
array[index] would remain legal, but index[array] would become
illegal.

If you were to think of the various forms of "+" as overloaded
operators, declared with some function-like syntax, the
pointer+integer and integer+pointer forms would have to be declared as
two separate functions. Of course, C doesn't declare its operators
that way; the point is that allowing both forms adds to the
complexity.

I'm not advocating such a change now; the bureaucratic overhead would
exceed any benefit. But it's one of the many things that I would do
differently if I were designing a C-like language from scratch. (In
the process, of course, I would commit new and original design errors
that K&R never dreamed of.)

--
Keith Thompson (The_Other_Keit h) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[pete]

Keith Thompson wrote:

In my opinion, it would have been no loss to the language if the
pointer were required to be the left operand. Certainly there would
be no loss of expressive power. As a side effect of such a change,
array[index] would remain legal, but index[array] would become
illegal.

If you were to think of the various forms of "+" as overloaded
operators, declared with some function-like syntax, the
pointer+integer and integer+pointer forms would have to be declared as
two separate functions. Of course, C doesn't declare its operators
that way; the point is that allowing both forms adds to the
complexity.

I'm not advocating such a change now; the bureaucratic overhead would
exceed any benefit.
But it's one of the many things that I would do
differently if I were designing a C-like language from scratch. (In
the process, of course, I would commit new and original design errors
that K&R never dreamed of.)

Your opinion is missing the part which explains why you
want index[array] to be illegal.
What benefit?

--
pete

[pete]

Tom St Denis wrote:

Joshua Neuheisel wrote:

The following code compiles with gcc 3.2.2 and Visual C++ 6:

#include <stdio.h>
int main()
{
int a[2] = {3, 4};
printf ("%d\n", 0[a]);
return 0;
}

Then 0[a] simply means *(&0 + a)

&0 isn't allowed.

--
pete

[Keith Thompson]

pete <pf*****@mindsp ring.com> writes:

Keith Thompson wrote:

[...]

I'm not advocating such a change now; the bureaucratic overhead would
exceed any benefit.
But it's one of the many things that I would do
differently if I were designing a C-like language from scratch. (In
the process, of course, I would commit new and original design errors
that K&R never dreamed of.)

Your opinion is missing the part which explains why you
want index[array] to be illegal.
What benefit?

What's the benefit of making such a counterintuitiv e construct legal?
As the C FAQ says, "This unsuspected commutativity is often mentioned
in C texts as if it were something to be proud of, but it finds no
useful application outside of the Obfuscated C Contest".

As I said, I'm not advocating making such a change, merely regretting
(mildly) that the feature was put into the language in the first
place.

If compatibility were not an issue, would you really want both
array[index] and index[array] to be valid? If so, why?

--
Keith Thompson (The_Other_Keit h) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"